VPN

[Does m0n0wall support IPSec pass-through?]

Hi All,

I’m facing an IPSec pass-through issue.

I already got an answer from David regarding this issue but would appreciate to have the community’s opinion.

My question is the following:

Does m0n0wall support IPSec pass-through?

I have been told that release 1.3b2 does the job.
Is this correct?

If so, I’ll probably use this beta into production environment.

Our network is something like:

{internet}----[ ADSL modem, bridged]-----[m0n0]------[LAN]

A machine from inside our LAN needs to open
an IPSEC connection to a company outside our small LAN:

[other-company] ----{internet}----[ADSL modem, bridged]-----[m0n0]------[LAN]

We use m0n0wall as our main firewall and VPN-PPTP server (small office ~10 machines)

Thank you in advance for help and comments

Thomas.

I have multiple tunnels set up on my m0n0wall to remote m0n0 installs...and I can VPN via IPsec into my company without issue. This is using 1.23.

The only thing I can think of that may be causing you problems is an MTU that's too high and is fragmenting the VPN packets before the tunnel could be established.

[through]

In my case "the VPNs" are not set on my m0n0wall (my m0n0 is not an end point).

As explained the VPN connection needs to pass "through" the m0n0wall.

I guess my point wasn't too clear...

I have <b>both</b> IPsec tunnels between m0n0walls and I can <b>also</b> pass through IPsec VPN traffic from my laptop to my company.

That's why I suggested that the problem for you could be a MTU issue due to your WAN connection being DSL.

[inside]

My scenario is slightly different :

The machine is inside my network, behind m0n0wall.
This means that the machine is NATed :

Machine----m0n0wall---modem---Internet

The VPN server is somewhere else in the wild internet.

Question :

Is my machine able to initiate a VPN connection to that server?

(VPN, IPSec)

OK, to be short and sweet...Yes, it will work. If it's not working, then troubleshooting is needed.

I too am having problems connecting to an IPSEC VPN using my m0n0. From a system inside the m0n0's  LAN interface out to a VPN server at my company.

Put my inferior linksys  back in place, and it works again.

Prior history of discussion on the old m0n0wall mail list indicates this may be a NAT Traversal (NAT-T) issue. I have upgraded to 1.3b2 and enabled NAT-T, still with no success.

Would love to provide firewall state details to Manuel or anyone willing to assist, as it sounds like this is a major issue with some VPN configurations. I might even be able to set up a sniffer outside the WAN interface to see what's going on, with a little guidance on what to look for.

So, if you tried two different versions of m0n0wall, including one that supposedly fixes this exact problem, yet continue to have problems...I would look at other factors.

What is your ISP type? As mentioned earlier, MTU problems can prevent VPN tunnels from coming up easily. Are you allowing all LAN traffic outward, or do you have any funny firewall rules?

Best way to see if something is configured wrong is to look at http://your-m0n0wall/status.php and post the relevant info here.

(edit: the text of my reply didn't get posted, only the attachment)
Hi Danne, thanks for the reply.

The ISP is cable-modem. As mentioned, the change from a run-of-the-mill Linksys to the m0n0wall (after many different configuration and version attempts) is now preventing access to this VPN connection.

I have not modified the default MTU setting. All LAN traffic is allowed (LAN -> any). At this time, no additional firewall rules beyond the LAN->any rule. I did at one point add a whole series of rules to explicitly allow the required ports and protocols to/from the VPN endpoint IP ranges (even opened up rules allowing any traffic to/from those IP ranges), to no avail.

At this point, I have basically a fresh-install of 1.3b2, except for the setting to turn on NAT-T.

I have also tried Manuel Kasper's suggestion posted here http://m0n0.ch/wall/list/showmsg.php?id=253/51  to turn off the portmap rule temporarily. This also appears to have no effect on my ability to connect to this VPN.

Thanks for the offer to look through my status output (attached).

Willing to try lots of things, just need more suggestions. I also think that with the default level of configuration I have here and the many times I've seen this type of inquiry, and the NAT-T changes being made, there must be some type of problem with the way m0n0 is passing IPSEC packets...

Thanks,
deanlester

So, if you tried two different versions of m0n0wall, including one that supposedly fixes this exact problem, yet continue to have problems...I would look at other factors.

What is your ISP type? As mentioned earlier, MTU problems can prevent VPN tunnels from coming up easily. Are you allowing all LAN traffic outward, or do you have any funny firewall rules?

Best way to see if something is configured wrong is to look at http://your-m0n0wall/status.php and post the relevant info here.

Make sure your client VPN is connecting to the VPN Concentrator via UDP.  If you are trying to make an IPSEC connection over TCP it won't work through NAT.  So you will need a server and client that can make the connection via UDP. 

Most all corporate (enterprise level) VPN Concentrators and clients are set this way so the employees can work from hot spots, home networks, etc.  Check your client first, it should have an option to use UDP instead of TCP.  If that connection won't establish, you will need to contact the person who manages the VPN Concentrator and ask them to enable that feature.

You can also tell m0n0wall to allow IPsec fragmented packets (System --> Advanced) this will help if your VPN is using fragmented TCP packets to encapsulate ESM IPSEC. 

I'm having the exact same problem.  I'm currently thinking that there is some kind of problem with IPSEC packet fragmentation.

I have a Soekris box running m0n0wall 1.3b2 as a firewall/router; the WAN is connected to Speakeasy DSL.  The system has been running fine for 3+ years.  I'm trying to connect to my company's VPN; I have no idea what it's running, other that I suspect that it's a Windows-based system.  I'm running OS X and using IPSecuritas 3.0 beta to try to connect. 

The VPN connection seems to be made fine, and logs in, and I can get to one or two resources, but nothing past that, and nothing of any size.  If I remove the router and connect directly to the modem, everything works perfectly.  If I put a Linksys WRT54G in, everything works fine.

On the status page I see fragmented packets in the logs.  I have enabled "allow fragmented packets" in Advanced, but it doesn't seem to make a difference.  The log looks like this:

Mar 24 20:50:53 firewall ipmon[93]: 20:50:53.267999 sis0 @0:13 b <VPN IP> -> <local ip> PR esp len 20 (1488) (frag 7404:1468@64) IN bad NAT

I see a lot of these in the log.   I've tried a bunch of different things, but nothing seems to work.  Changing the MTU on the WAN to 1400 sounded promising but resulted in nothing working on the WAN at all.

I greatly appreciate any ideas!  Thanks!

I can confirm that this issue is not present with pfSense, tried this weekend. It dogs out my Soekris net4501 (memory pressure), but it does work perfectly for IPSec VPN connections to my corporate VPN "out of the box" with no special rules or configs, just turning on the "enable IPSec" function.

I'd love to stick with M0n0wall, but failure to connect through the monowall to my corporate VPN is a deal-breaker.

It appears something in mono (1.23 and 1.3b2) is blocking or not correctly passing IPSec UDP packets with NAT-T, as confirmed by Manuel Kasper http://m0n0.ch/wall/list/showmsg.php?id=253/51. Unfortunately, the proposed solution in that post to turn off the portmap rule had no effect, nor did the MTU setting change, in addition to the new NAT-T feature in 1.3b2.

Other suggestions? In the meantime I guess I have to run with pfSense overloading my soekris...

thanks,
dean

I can confirm that this issue is not present with pfSense, tried this weekend. It dogs out my Soekris net4501 (memory pressure), but it does work perfectly for IPSec VPN connections to my corporate VPN "out of the box" with no special rules or configs, just turning on the "enable IPSec" function.

I'd love to stick with M0n0wall, but failure to connect through the monowall to my corporate VPN is a deal-breaker.

It appears something in mono (1.23 and 1.3b2) is blocking or not correctly passing IPSec UDP packets with NAT-T, as confirmed by Manuel Kasper http://m0n0.ch/wall/list/showmsg.php?id=253/51. Unfortunately, the proposed solution in that post to turn off the portmap rule had no effect, nor did the MTU setting change, in addition to the new NAT-T feature in 1.3b2.

Other suggestions? In the meantime I guess I have to run with pfSense overloading my soekris...

thanks,
dean

Hello All,

This is my first post so please understand if I am "nooby"!

I am also having this IPsec pass through issue with a Cisco VPN client on the LAN while using any new versions of Monowall I have used 1.22/1.23/1.3b and tried all the following:

I have a cable type connection in Switzerland.

1) checked the MTU size as described above - usually not an issue for cable - to no avail.
2) checked the NAT-T traversal problem - I dont why this would help as it should be for tunnels from the firewall itself - but nevertheless I tried it - to no avail.
3) Tried the Ipsec "allow fragments" on both LAN and WAN interfaces - to no avail.
4) Tried to do the fix proposed by Manuel at the link above using exec.php - and nothing....

I am beginning to suspect that the network address type (164.32.x.x) which I am using, is conflicitng with the corporate one - but I have contacted the IT group and they have said not!

Also I wanted to mention that when I removed the cables from WAN and LAN and plugged them into my Linksys crap, IPsec pass through using the Cisco client works fine.


Any other suggestions?

Best Regards,

Cisco VPN client works just fine with m0n0wall, I use it all the time. Your concentrator/router/PIX (whatever terminates the IPsec connection) needs to have NAT-T enabled. With that it should work fine. If not, you have some sort of client or endpoint issue unrelated to m0n0wall.

[cmb,I'm the one who initiated the present thread.I would like to add the following information :- I tried the same combinations warlock did, with no result- the VPN server I tried to connect to is a Checkpoint VPN server- the client is Checkpoint too- tried 1.22 and 1.23- adsl-modem-bridged-mode + m0n0 + machine => no VPN connection- adsl-modem-IPSec-passthrough_enabled + machine => VPN connection OKAs said in my first post, this issue is really a concern for the company I work for.As I was not able to trust m0n0 regarding this VPN problem, we had to go for a second and dedicated DSL connection (until I'am able to provide another solution).I really hope that this issue will not last and 1.24 or 1.3 will be able to handle IPSec Passthrough correctly.Thank you all for your posts, suggestions and help.Thanks to Manuel and the m0n0 team, for the great work.Regards,Thomas.]

cmb,

I'm the one who initiated the present thread.
I would like to add the following information :

- I tried the same combinations warlock did, with no result
- the VPN server I tried to connect to is a Checkpoint VPN server
- the client is Checkpoint too
- tried 1.22 and 1.23
- adsl-modem-bridged-mode + m0n0 + machine => no VPN connection
- adsl-modem-IPSec-passthrough_enabled + machine => VPN connection OK

As said in my first post, this issue is really a concern for the company I work for.

As I was not able to trust m0n0 regarding this VPN problem, we had to go for a second and dedicated DSL connection (until I'am able to provide another solution).

I really hope that this issue will not last and 1.24 or 1.3 will be able to handle IPSec Passthrough correctly.

Thank you all for your posts, suggestions and help.

Thanks to Manuel and the m0n0 team, for the great work.

Regards,

Thomas.