[ previous ] [ next ] [ threads ]
 From:  "Jonathan De Graeve" <Jonathan dot De dot Graeve at imelda dot be>
 To:  "Manuel Kasper" <mk at neon1 dot net>, "Polus, Tomasz" <tomek at polvision dot com dot pl>
 Cc:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] FW: m0n0wall blocks incoming UDP 500
 Date:  Wed, 15 Mar 2006 13:56:54 +0100
All Nortel Contivity VPN Clients work too behind M0n0wall


-----Oorspronkelijk bericht-----
Van: Manuel Kasper [mailto:mk at neon1 dot net] 
Verzonden: woensdag 15 maart 2006 13:54
Aan: Polus, Tomasz
CC: m0n0wall at lists dot m0n0 dot ch
Onderwerp: RE: [m0n0wall] FW: m0n0wall blocks incoming UDP 500

On 15.03.06 09:27 +0100, Polus, Tomasz wrote:

> IMO this is a huge issue for all clients using simple VPN-IPSEC
> outgoing connections.... Is there anyone (m0n0wall developer maybe)
> who can make more thorough troubleshooting?

If you'd like to contribute to a solution, you should provide more
information - the output from http://m0n0wall/status.php after a
failed VPN connection attempt would be very helpful, as it would
allow us to determine which rule caused the packets to be blocked and
what the state of the NAT table was.

I've used the following VPN clients successfully behind m0n0wall with
various remote VPN gateways, some of which didn't support NAT-T (and
it worked anyway, as is to be expected with ESP in tunnel mode):

- SafeNet SoftRemote
- Cisco VPN client
- TheGreenBow VPN client
- Equinux VPN Tracker
- SonicWall Global VPN client

One thing that should be noted is that m0n0wall doesn't attempt to
preserve the LAN host's source port when doing outbound NAT. If you
have a remote VPN device that insists on the VPN client's port being
500, then it won't work. Some other firewalls attempt to preserve the
port for the first connection, and some don't.

- Manuel

To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch