I have problems connecting IPSEC VPN clients on the masqueraded network to outside VPN servers. It looks like this: ipsec-user | 192.168.1.10 (DHCP assigned) | | 192.168.1.1 fw-1 (shorewall, Linux 2.6) | 20.20.20.20 (internet) | 30.30.30.30 fw-2 (IPSEC VPN endpoint) | 192.168.100.1 | | 192.168.100.2 server ipsec-user (a road warrior) is supposed to create an IPSEC tunnel to his home network (192.168.100.0/24) and be able to communicate with server. Other users on the 192.168.1.0/24 network is not supposed to have any access to the 192.168.100.0/24 network. Thats why I don''t create a tunnel between fw-1 and fw-2. The ipsec-user just happens to temporary use our 192.168.1.0/24 network for internet access. It work''s if the ipsec-user is directly connected to the internet (using non-private) addresses. But when the user is sitting on our network the tunnel cannot be established. I don''t find any blocked traffic in the shorewall logs on fw-1 (I have log-level info on all DROP and REJECT rules). Is the above at all possible without any special hacking in the fw-1 firewall, or is the masquerading that is done on fw-1 making it impossible to establish VPN tunnels thru the fw-1 firewall? Any pointers in the right direction is wanted, also RTFM answers to what manual I should read :-) /Stefan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Nilsen wrote: | | I don''t find any blocked traffic in the shorewall logs on fw-1 (I have | log-level info on all DROP and REJECT rules). | | Is the above at all possible without any special hacking in the fw-1 | firewall, or is the masquerading that is done on fw-1 making it | impossible to establish VPN tunnels thru the fw-1 firewall? | | Any pointers in the right direction is wanted, also RTFM answers to what | manual I should read :-) You might take a look at http://shorewall.net/VPN.htm. The other thing is that the ipsec client must not be using AH (Authentication Headers -- Protocol 51); that protocol does not work through NAT while ESP (Protocol 50) does. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBNiqsO/MAbZfjDLIRAjAkAKC3+rjyQPgk9onk+0vQkqL7vBPCCQCeNqDA HZXmC3l5J/OPCauqjSGIpTM=UVsd -----END PGP SIGNATURE-----
> | Is the above at all possible without any special hacking in the > | fw-1 firewall, or is the masquerading that is done on fw-1 making > | it impossible to establish VPN tunnels thru the fw-1 firewall? > | > | Any pointers in the right direction is wanted, also RTFM answers to > | what manual I should read :-) > > You might take a look at http://shorewall.net/VPN.htm. The other > thing is that the ipsec client must not be using AH (Authentication > Headers -- Protocol 51); that protocol does not work through NAT > while ESP (Protocol 50) does.I have looked at that documentation page but it does not handle DHCP assigned addresses. ESP is used, no AH, and I believe I have now found out what happens. The response from the remote VPN server is too large to fit in one packet, and is fragmented. fw-1 does not seem to forward that response back to the VPN client. I have tried to set CLAMPMSS=Yes and to set the mtu size on inside and outside interfaces on fw-1 to 1300, without any success. Is there something else I might do? I also have other VPN tunnels terminated on the fw-1, but can that be a problem for the masqueraded VPN connection...? /Stefan
Stefan Nilsen wrote:>>| Is the above at all possible without any special hacking in the >>| fw-1 firewall, or is the masquerading that is done on fw-1 making >>| it impossible to establish VPN tunnels thru the fw-1 firewall? >>| >>| Any pointers in the right direction is wanted, also RTFM answers to >>| what manual I should read :-) >> >>You might take a look at http://shorewall.net/VPN.htm. The other >>thing is that the ipsec client must not be using AH (Authentication >>Headers -- Protocol 51); that protocol does not work through NAT >>while ESP (Protocol 50) does. > > > I have looked at that documentation page but it does not handle DHCP > assigned addresses. > > ESP is used, no AH, and I believe I have now found out what happens. The > response from the remote VPN server is too large to fit in one packet, > and is fragmented. fw-1 does not seem to forward that response back to > the VPN client. > > I have tried to set CLAMPMSS=Yes and to set the mtu size on inside and > outside interfaces on fw-1 to 1300, without any success. > > Is there something else I might do? > > I also have other VPN tunnels terminated on the fw-1, but can that be a > problem for the masqueraded VPN connection...? >Its worth noting that putting a host name instead of a ip address in tunnels, can cause shorewall to hang waiting for a dns reply if a lookup is performed before the dhcp lease has been stabilised. If you use something similar to ddclient to upate the dns you need a delay before starting the vpn/ipsec tunnel. Dyndns is very quick to update its dns. mvh Richard
On Wednesday 01 September 2004 14:55, Stefan Nilsen wrote:> > | Is the above at all possible without any special hacking in the > > | fw-1 firewall, or is the masquerading that is done on fw-1 making > > | it impossible to establish VPN tunnels thru the fw-1 firewall? > > | > > | Any pointers in the right direction is wanted, also RTFM answers to > > | what manual I should read :-) > > > > You might take a look at http://shorewall.net/VPN.htm. The other > > thing is that the ipsec client must not be using AH (Authentication > > Headers -- Protocol 51); that protocol does not work through NAT > > while ESP (Protocol 50) does. > > I have looked at that documentation page but it does not handle DHCP > assigned addresses.You could always configure your DHCP server to assign the Roadwarrior a fixed IP.> > ESP is used, no AH, and I believe I have now found out what happens. The > response from the remote VPN server is too large to fit in one packet, > and is fragmented. fw-1 does not seem to forward that response back to > the VPN client. >Is this the ESP packets or the ISAKMP packets?> I have tried to set CLAMPMSS=Yes and to set the mtu size on inside and > outside interfaces on fw-1 to 1300, without any success.CLAMPMSS only affects TCP -- you are using UDP and ESP.> > Is there something else I might do? >Not that I can think of.> I also have other VPN tunnels terminated on the fw-1, but can that be a > problem for the masqueraded VPN connection...? >Not unless your tunnels have the same remote gateway. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> You could always configure your DHCP server to assign the Roadwarrior > a fixed IP.Perhaps for one or two road warriors, but I want to make this as seamless as possible.> > ESP is used, no AH, and I believe I have now found out what > > happens. The response from the remote VPN server is too large to > > fit in one packet, and is fragmented. fw-1 does not seem to forward > > that response back to the VPN client. > > Is this the ESP packets or the ISAKMP packets?It is the ISAKMP packets. The ISAKMP packet has the More fragments flag set, and the packet after is an IP fragment.> > Is there something else I might do? > > Not that I can think of.Maybe there is any kernel module i need to have loaded? shorewall/modules have the following lines: loadmodule ip_tables loadmodule iptable_filter loadmodule ip_conntrack loadmodule ip_conntrack_ftp loadmodule ip_conntrack_tftp loadmodule ip_conntrack_irc loadmodule iptable_nat loadmodule ip_nat_ftp loadmodule ip_nat_tftp loadmodule ip_nat_irc> > I also have other VPN tunnels terminated on the fw-1, but can that > > be a problem for the masqueraded VPN connection...? > > Not unless your tunnels have the same remote gateway.I have no tunnels for the same remote gateway. /Stefan
> Its worth noting that putting a host name instead of a ip address in > tunnels, can cause shorewall to hang waiting for a dns reply if a > lookup is performed before the dhcp lease has been stabilised. If you > use something similar to ddclient to upate the dns you need a delay > before starting the vpn/ipsec tunnel. Dyndns is very quick to update > its dns.Pure IP addresses is used everywhere, on the VPN clients, and in the other tunnels I use. The server the VPN client connects to has a fixed IP. /Stefan
On Wednesday 01 September 2004 18:17, Stefan Nilsen wrote:> > Maybe there is any kernel module i need to have loaded? >There are no modules dealing with IPSEC passthrough... Does the Roadwarrior''s client support NAT traversal? That might be the only solution. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
> There are no modules dealing with IPSEC passthrough... > > Does the Roadwarrior''s client support NAT traversal? That might be > the only solution.It is Windows XP Prof with all patches. That includes the patch for NAT-T support. But I don''t see any traffic to or from port 4500... The native IPSEC implementation is used, with a tool that configures IPSEC with the dynamic address on the client. In the destination VPN server, running racoon and Linux 2.6, it says IPSEC-SA established and then it sends the big fragmented packet to the client, wich seems to get silently dropped in the firewall...
On Wednesday 01 September 2004 19:52, Stefan Nilsen wrote:> > In the destination VPN server, running racoon and Linux 2.6, it says > IPSEC-SA established and then it sends the big fragmented packet to the > client, wich seems to get silently dropped in the firewall...Well, "shorewall status" will show you what happens to every packet processed by the firewall. I''m not going to stay up all night trying to find out what is happening to the lost packets but you are welcome to. Note that Netfilter requires that all fragments be received and reassembled before the resulting packet is passed through Netfilter. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Hi there, the last time I had to deal with something similar I actually had to use 1296 as MTU. I still haven''t figured out why but I am working on it. -- Axel Westerhold Congos Inc. Technical Lead PK: 1EF597FA Stefan Nilsen wrote:>>| Is the above at all possible without any special hacking in the >>| fw-1 firewall, or is the masquerading that is done on fw-1 making >>| it impossible to establish VPN tunnels thru the fw-1 firewall? >>| >>| Any pointers in the right direction is wanted, also RTFM answers to >>| what manual I should read :-) >> >>You might take a look at http://shorewall.net/VPN.htm. The other >>thing is that the ipsec client must not be using AH (Authentication >>Headers -- Protocol 51); that protocol does not work through NAT >>while ESP (Protocol 50) does. >> >> > >I have looked at that documentation page but it does not handle DHCP >assigned addresses. > >ESP is used, no AH, and I believe I have now found out what happens. The >response from the remote VPN server is too large to fit in one packet, >and is fragmented. fw-1 does not seem to forward that response back to >the VPN client. > >I have tried to set CLAMPMSS=Yes and to set the mtu size on inside and >outside interfaces on fw-1 to 1300, without any success. > >Is there something else I might do? > >I also have other VPN tunnels terminated on the fw-1, but can that be a >problem for the masqueraded VPN connection...? > >/Stefan >_______________________________________________ >Shorewall-users mailing list >Post: Shorewall-users@lists.shorewall.net >Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-users >Support: http://www.shorewall.net/support.htm >FAQ: http://www.shorewall.net/FAQ.htm > >
On Wednesday 01 September 2004 19:52, Stefan Nilsen wrote:> > There are no modules dealing with IPSEC passthrough... > > > > Does the Roadwarrior''s client support NAT traversal? That might be > > the only solution. > > It is Windows XP Prof with all patches. That includes the patch for > NAT-T support. But I don''t see any traffic to or from port 4500... > > The native IPSEC implementation is used, with a tool that configures > IPSEC with the dynamic address on the client. > > In the destination VPN server, running racoon and Linux 2.6, it says > IPSEC-SA established and then it sends the big fragmented packet to the > client, wich seems to get silently dropped in the firewall...That is probably because you have a rule that accepts all ISAKMP from the net. The reason that the UDP DNAT rule that I show at http://shorewall.net/VPN.htm is required is that IPSEC clients often use a source port other than 500; so when the responding ISAKMP packets arrive, they cannot be associated with the preceding outgoing ones. If the firewall is accepting ISAKMP then these replies will be silently dropped. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key