Sorry to barge in on an old thread. I''m having the same trouble as the gent who started this thread. I''ve tried the options described and can''t seem to get the tunnel to pass packets through it. I''m using the Netscreen Remote VPN client (Safenet derivative) on a windows machine, trying to connect to a Netscreen 5xp at the other end. The connection fires up, but then I am not able to send anything through it. (Both the client and the remote device tell me that the connection is authenticated and up.) Kinka starting to lose my mind, so any help would be appreciated. Thanks, Richard Stovall PS Thanks for making Shorewall. I''ve been looking for something like this for a long time. ________________________________________________ The page that I referred you to (http://shorewall.sf.net/VPN.htm) gives you all of the rules you need to run an ipsec client behind Shorewall UNLESS=20 you have a loc->net policy of DROP or REJECT. In that case, you will also=20 need: ACCEPT loc net[:<ip of remote endpoint> udp 500 500 ACCEPT loc net[:<ip of remote endpoint>] 50 If you omit the ":<ip of remote endpoint>", local clients will be able to=20 try to connect to any internet host. If you are having problems using those rules then who don''t you tell us=20 what problems you are seeing and we''ll try to help? -Tom
--On Friday, January 24, 2003 12:53 AM -0800 richard <richard@shuffle.com> wrote:> Sorry to barge in on an old thread. I''m having the same trouble as the > gent who started this thread. I''ve tried the options described and can''t > seem to get the tunnel to pass packets through it. I''m using the > Netscreen Remote VPN client (Safenet derivative) on a windows machine, > trying to connect to a Netscreen 5xp at the other end. The connection > fires up, but then I am not able to send anything through it. (Both the > client and the remote device tell me that the connection is authenticated > and up.) Kinka starting to lose my mind, so any help would be > appreciated. >Given the wealth of information that you have provided, I don''t see how we could possibly fail to pinpoint the problem. A trip to the Netscreen web site indicates that the 5XP supports NAT traversal which as I understand it means that the ESP and/or AH packets are encapsulated in UDP packets with destination port 4500. When you try to pass traffic through the tunnel, are you seeing any Shorewall messages being generated in the firewall''s log? -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: teastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Thanks for the quick reply. The most frustrating thing is that there is nothing being generated in the syslog, even though I''ve set the log-level to debug. Below are the shorewall configuration files as I have them set up. If it helps, here is a message I received from Netscreen about the problem. ##Begin communique from Netscreen Support## Dear Richard, The only thing that you should need to allow on the firewall in the middle, is UDP 500. NAT Traversal encapsulates the IPSec packet within UDP 500. On the client it is transparent. On the netscreen, you must enable NAT Traversal on the VPN Gateway. That should be all there is to it. Check that NAT T is enabled on the netscreen. ##End communique from Netscreen Support## Nat traversal is enabled on the 5xp. Here are the shorewall config options by file: #common# . /etc/shorewall/common.def run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP #end common# #common.def# run_iptables -A common -p icmp -j icmpdef run_iptables -A common -m state -p tcp --state INVALID -j DROP run_iptables -A common -p udp --dport 137:139 -j REJECT run_iptables -A common -p udp --dport 445 -j REJECT run_iptables -A common -p tcp --dport 135 -j reject run_iptables -A common -p udp --dport 1900 -j DROP run_iptables -A common -d 255.255.255.255 -j DROP run_iptables -A common -d 224.0.0.0/4 -j DROP run_iptables -A common -p tcp --dport 113 -j reject #end common.def# #interfaces# net eth0 detect routefilter,norfc1918 loc eth1 detect routestopped #end interfaces# #policy# loc net ACCEPT debug fw net ACCEPT net all DROP debug all all REJECT debug #end policy# #rules# ACCEPT fw net tcp 53 ACCEPT fw net udp 53 ACCEPT loc net udp 500 500 ACCEPT loc net 50 DNAT net:64.83.15.158 loc:192.168.1.20 50 DNAT net:64.83.15.158 loc:192.168.1.20 udp 500 ACCEPT loc fw tcp 22 #end rules# All of the other config files remain unchanged from the default ''two-interfaces'' setup. I have started up the VPN and then tried to ping the remote machine from the local client while sniffing packets with cold. It looks to me like the connection is dying at the firewall, but I can''t tell from the logs why this is so. Here are some representative results from cold: #Begin cold data from eth0 (external)# [PKT] PKT: Frame: number 1, size 60 of 60, arrived at 1043427081.176907 [MAC - Ethernet Frame] MAC: Source: 00-10-db-2e-d2-31, NETSCREEN TECHNOLOGIES, INC., Indiv./Univ. MAC: Dest: 00-20-78-14-dd-2f, RUNTOP, INC., Indiv./Univ. MAC: Protocol = 0x0800, Internet IPv4 [IP Frame] IP: Version = 4, header length = 20 bytes IP: Type of Service = 0x00 IP: Total length = 29 bytes IP: Identification = 32227 IP: Flags = 0x0, IP: Fragment offset = 0 bytes IP: Time to live = 64 hops/seconds IP: Protocol = 17, UDP, User Datagram Protocol IP: Header checksum = 0x5cab IP: Source address = 64.83.15.158 IP: Destination address = 64.83.15.254 [UDP Frame] UDP: Source port = 500, isakmp, Well known UDP: Destination port = 1, TCP Port Service Multiplexer, Well known UDP: Message Length = 9 UDP: Checksum = 0x5ea4 ----- [PKT] PKT: Frame: number 2, size 43 of 43, arrived at 1043427081.798772 [MAC - Ethernet Frame] MAC: Source: 00-20-78-14-dd-2f, RUNTOP, INC., Indiv./Univ. MAC: Dest: 00-10-db-2e-d2-31, NETSCREEN TECHNOLOGIES, INC., Indiv./Univ. MAC: Protocol = 0x0800, Internet IPv4 [IP Frame] IP: Version = 4, header length = 20 bytes IP: Type of Service = 0x00 IP: Total length = 29 bytes IP: Identification = 21215 IP: Flags = 0x0, IP: Fragment offset = 0 bytes IP: Time to live = 127 hops/seconds IP: Protocol = 17, UDP, User Datagram Protocol IP: Header checksum = 0x48af IP: Source address = 64.83.15.254 IP: Destination address = 64.83.15.158 [UDP Frame] UDP: Source port = 1, TCP Port Service Multiplexer, Well known UDP: Destination port = 500, isakmp, Well known UDP: Message Length = 9 UDP: Checksum = 0x5ea4 #End cold data from eth0 (external)# #Begin cold data from eth1 (internal)# ----- [PKT] PKT: Frame: number 6, size 60 of 60, arrived at 1043427602.695804 [MAC - Ethernet Frame] MAC: Source: 00-01-80-26-b5-a5, AOpen, Inc., Indiv./Univ. MAC: Dest: 00-a0-cc-3a-46-86, LITE-ON COMMUNICATIONS, INC., Indiv./Univ. MAC: Protocol = 0x0800, Internet IPv4 [IP Frame] IP: Version = 4, header length = 20 bytes IP: Type of Service = 0x00 IP: Total length = 29 bytes IP: Identification = 21522 IP: Flags = 0x0, IP: Fragment offset = 0 bytes IP: Time to live = 128 hops/seconds IP: Protocol = 17, UDP, User Datagram Protocol IP: Header checksum = 0xd510 IP: Source address = 192.168.1.20 IP: Destination address = 64.83.15.158 [UDP Frame] UDP: Source port = 500, isakmp, Well known UDP: Destination port = 500, isakmp, Well known UDP: Message Length = 9 UDP: Checksum = 0xeb45 ----- [PKT] PKT: Frame: number 7, size 214 of 214, arrived at 1043427605.483846 [MAC - Ethernet Frame] MAC: Source: 00-a0-cc-3a-46-86, LITE-ON COMMUNICATIONS, INC., Indiv./Univ. MAC: Dest: 00-01-80-26-b5-a5, AOpen, Inc., Indiv./Univ. MAC: Protocol = 0x0800, Internet IPv4 [IP Frame] IP: Version = 4, header length = 20 bytes IP: Type of Service = 0x00 IP: Total length = 200 bytes IP: Identification = 32458 IP: Flags = 0x0, IP: Fragment offset = 0 bytes IP: Time to live = 63 hops/seconds IP: Protocol = 17, UDP, User Datagram Protocol IP: Header checksum = 0xeaad IP: Source address = 64.83.15.158 IP: Destination address = 192.168.1.20 [UDP Frame] UDP: Source port = 500, isakmp, Well known UDP: Destination port = 500, isakmp, Well known UDP: Message Length = 180 UDP: Checksum = 0x17b5 #End cold data from eth1 (internal)# Notice that the MAC address of 64.83.15.158 (the remote gateway) is different on the reports from the different interfaces. I suppose this is good, but it is not actually the MAC address of the endpoint at the other end of the tunnel. Weird. Anyway, thank you SO MUCH for taking the time to help with this. With much appreciation, Richard Stovall __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
--On Friday, January 24, 2003 9:23 AM -0800 Richard Stovall <richado@yahoo.com> wrote:> Thanks for the quick reply. The most frustrating > thing is that there is nothing being > generated in the syslog, even though I''ve set the > log-level to debug.Thereby hiding any messages rather than revealing them (unless you also configured syslogd to log DEBUG messages).> Below are the > shorewall configuration files as I have them set up. > If it helps, here is a message I > received from Netscreen about the problem. > >## Begin communique from Netscreen Support## > > Dear Richard, > The only thing that you should need to allow on the > firewall in the middle, is UDP 500. > NAT Traversal encapsulates the IPSec packet within UDP > 500. On > the client it is transparent. On the netscreen, you > must enable NAT Traversal on the > VPN Gateway. That should be all there is to it. > Check that NAT T is enabled on the > netscreen. > >## End communique from Netscreen Support## > > Nat traversal is enabled on the 5xp. > > Here are the shorewall config options by file: > > > ACCEPT loc net 50 > DNAT net:64.83.15.158 loc:192.168.1.20 50 > DNAT net:64.83.15.158 loc:192.168.1.20 udp 500That should be all you need assuming that the remote 5xp is 64.83.15.158 and your local client is 192.168.1.20.> I have started up the VPN and then tried to ping the > remote machine from the local > client while sniffing packets with cold.What type of tunnel is this? Host-to-host? Host-to-subnet? In the latter case, you won''t be able to ping the remote gateway through the tunnel but rather you will be able to ping hosts BEHIND the remote gateway.> It looks to > me like the connection is dying at > the firewall, but I can''t tell from the logs why this > is so.>From the traces that you included, you are going to have to explain why youthink that. I see traffic both inbound and outbound on both sides of the firewall. < traces deleted>> > Notice that the MAC address of 64.83.15.158 (the > remote gateway) is different on the > reports from the different interfaces. I suppose this > is good, but it is not actually > the MAC address of the endpoint at the other end of > the tunnel. Weird.Sigh -- MAC addresses are ETHERNET ADDRESSES!!! If you are snooping traffic between a host and your firewall, the MAC addresses you see are either the MAC address of the local NIC in your firewall OR the MAC address of the local host!!!!! If you are snooping traffic between your firewall and the 5XP (which looks like it is on the same subnet as your firewall''s external IF), the MAC addresses you see are either the MAC address of the 5xp OR the MAC address of the external interface in your firewall!!! -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: teastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
--On Friday, January 24, 2003 10:21 AM -0800 Tom Eastep <teastep@shorewall.net> wrote:> > > --On Friday, January 24, 2003 9:23 AM -0800 Richard Stovall > <richado@yahoo.com> wrote: > >> Thanks for the quick reply. The most frustrating >> thing is that there is nothing being >> generated in the syslog, even though I''ve set the >> log-level to debug.One thing you might try is a minimum configuration test: a) shorewall clear b) iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQ That eliminates Shorewall entirely from your setup. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: teastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net