> The support guidelines clearly state that you should clear the netfilter > counters, try the failing connection, > take the dump, and explain in the report what you tried and how it failed.
Tom, Thanks for your patience with me; I hope I followed the correct procedure this time. I wish to establish a VPN connection between my local firewall (212.115.197.253 - running shorewall and racoon) which serves both LAN's 192.168.0.0/24 and 192.168.6.0/24, and a remote Draytek router (92.64.158.73 - capable of VPN tunneling) which serves 192.168.21.0/24. After resetting shorewall counters I started racoon in foreground mode and started the tunnel from the remote Draytek. From the racoon log I can tell the tunnel is up. Next I tried pinging the device 192.168.21.51 from the local firewall, from my own desktop (192.168.0.64) and from a server in the other local subnet (192.168.6.1). None of them got a reply. In fact, if I start the tunnel from the local firewall by pinging the remote IP 192.168.21.51, I recieve the error "From 192.168.0.254 icmp_seq=1 Destination Host Unreachable" the moment the tunnel is up. Another thing I don't understand is that this specific tunnel to the 192.168.21.0 subnet needs an extra sainfo rule "sainfo address 212.115.197.253/32 any address 192.168.21.0/24 any". Without this rule, racoon throws "ERROR: failed to get sainfo." at me. Similar tunnels to other Drayteks at other remote sites do not need this extra rule. > All we have here is a dump and an observation about a particular connection > so I can only tell you that the > [UNREPLIED] entry is an attempt to connect from 212.115.197.253 to > 192.168.21.51. There is no security policy > covering that connection so the traffic DID NOT GO THROUGH THE TUNNEL. Given > that it was addressed to an RFC 1918 > address, the packet was simply dropped when or before it reached the internet > core routers. It is not clear to me why 212.115.197.253 would try to connect to the LAN side of the remote Draytek and not the WAN side at 92.64.158.73. I did create a security policy covering that connection. > If you look down in the section of the dump titled PFKEY SPD, you will see > all of the Security Policies that you > have defined. The only one with source 212.115.197.253 is from gateway to > gateway. So the other gateway is the only > host that this gateway can communicate with through the tunnel. > As spelled out in the Shorewall IPSEC 2.6 documentation, it takes 8 security > policies to completely cover the > combinations when connecting two local subnets via IPSEC. I thought I needed 8 security policies for full encrypted connectivity between the subnets. As I assumed I only needed encrytion between both gateways (as in http://www.ipsec-howto.org/x304.html#TUNNEL), I did not created all 8 but only the two as in the example. In my last attempt I did create all 8. Thanks again for your time and patience, Wouter
shorewall.dump.gz
Description: Binary data
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
