Hi all,
I finally got my IPSec tunnel from my Fedora firewall system (running
Shorewall 4.0.6) to a remote Draytek Router up-and-running, but I''m
having
difficulties directing traffic through the tunnel. From the output of
"racoon -F -f racoon.conf" and the connection status page of the
Draytek I
can tell the tunnel is UP, but ping and traceroute requests to several hosts
from and to both directions fail and also tcpdump reveals no traffic going
through. Maybe that''s because of my limited knowledge of tcpdump or
because
of some missing routing entries (or both), but I sure could use someone
helping me in the right direction.
SHOREWALL SHOW output is attached; IP ADRR SHOW and IP ROUTE SHOW output
are:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:10:18:30:53:1c brd ff:ff:ff:ff:ff:ff
inet 192.168.0.254/24 brd 192.168.0.255 scope global eth2
inet6 fe80::210:18ff:fe30:531c/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:19:b9:f2:f9:62 brd ff:ff:ff:ff:ff:ff
inet 192.168.6.254/24 brd 192.168.6.255 scope global eth1
inet6 fe80::219:b9ff:fef2:f962/64 scope link
valid_lft forever preferred_lft forever
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 00:19:b9:f2:f9:60 brd ff:ff:ff:ff:ff:ff
inet 212.115.197.253/29 brd 212.115.197.255 scope global eth0
inet6 fe80::219:b9ff:fef2:f960/64 scope link
valid_lft forever preferred_lft forever
212.115.197.248/29 dev eth0 proto kernel scope link src 212.115.197.253
192.168.6.0/24 dev eth1 proto kernel scope link src 192.168.6.254
192.168.21.0/24 dev eth0 scope link
192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.254
169.254.0.0/16 dev eth2 scope link
default via 212.115.197.254 dev eth0
TIA
Wouter
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Wouter Amsterdam wrote:> I finally got my IPSec tunnel from my Fedora firewall system (running > Shorewall 4.0.6) to a remote Draytek Router up-and-running, but I''m > having difficulties directing traffic through the tunnel. From the > output of "racoon –F –f racoon.conf"and the connection status page of > the Draytek I can tell the tunnel is UP, but ping and traceroute > requests to several hosts from and to both directions fail and also > tcpdump reveals no traffic going through. Maybe that''s because of my > limited knowledge of tcpdump or because of some missing routing entries > (or both), but I sure could use someone helping me in the right direction. > > SHOREWALL SHOW output is attached; IP ADRR SHOW and IP ROUTE SHOW output > are:In the future, please include the output of ''shorewall dump'' rather than ''shorewall show'' (see http://www.shorewall.net/support.htm#Guidelines). The former only shows the contents of the filter table while the latter gives us a complete look at your configuration, including routing and IPSEC. In this instance, however, I think I can get you one step closer with the material you included. Using a 2.6 kernel with Racoon, there is no ipsec0 interface. So your vpn1 zone should be defined in terms of the eth0 interface rather than ipsec0. Another thing to keep in mind -- the traffic that goes through the tunnel is determined entirely by the IPSEC Security Associations that have been established; routing doesn''t enter into it in any way. -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 ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Tom, First of all: thanks for your swift reply earlier. I tried uploading the real dumpfile some time ago, but forgot to zip it. After a some time away from the office I now try again. I think I changed my config files according to http://www.shorewall.net/IPSEC-2.6.html, but still nothing. I checked and double-checked my racoon.conf and setkey.conf files, but maybe by now I have changed these files so often I''m overlooking a crucial detail? This time I did create the shorewall dump file (attached) and took some time analyzing it. In the 10th line of the Conntrack Table there seems to be some sort of communication between my firewall''s external IP and an internal IP at the remote site (vpn21) which is [UNREPLIED]. Does this mean traffic is going into the tunnel to the remote site, but does not return? TIA, Wouter ------------------------------------------------------------------------- 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=/
Wouter Amsterdam wrote:> dump file (attached) and took some time analyzing it.> In the 10th line of the Conntrack Table there seems to be some sort of> communication between my firewall''s external IP and an internal IP at> the remote site (vpn21) which is [UNREPLIED]. Does this mean traffic > is going into the tunnel to the remote site, but does not return? 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. 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. 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 can see no reason that zones loc6 and loc7 should not be able communicate with the remote network. Note though that you can totally eliminate Shorewall from the issue by doing ''shorewall clear'' then trying to communicate. If that doesn''t work then your Shorewall configuration is not the immediate cause of the problem. Be sure to ''shorewall start'' after the test since your firewall will be wide open after the ''shorewall clear''. -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 ------------------------------------------------------------------------- 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=/
> 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 ------------------------------------------------------------------------- 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=/
Wouter Amsterdam wrote: <absurdly-formatted post> Please -- fix your mailer. Each paragraph is one long line. I''m very busy right now and quoting an email like yours take 3 times as long as one that is correctly formatted. Thanks.> 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.So that means that your entries in /etc/shorewall/tunnels (or in the rules file if you take that approach) are correct.> 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).What happens if you ''shorewall clear''? I''m not going to ask that question again (I did in my last post). And if pinging doesn''t work after ''shorewall clear'' then please don''t post here again until - ping does work after ''shorewall clear'' but - stops working again after ''shorewall start''. Thanks, -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 ------------------------------------------------------------------------- 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=/