Hello! I have this situation / interfaces: Dsl0 - internet interface Eth0 - local network I have linux box with shorewall 2.2. And on the local network I also have a hardware router. I have connected WAN port with settings of my linux box and then created one more local network behind hardware router. It works fine. I then wanted to use VPN function of this hardware router, so i created ACCEPT and DNAT rules on shorewall so that all traffic is permited from one external IP to this internat IP of hardware router. Now i know that the connection works fine if i try to send packets from my hardware router to other side, but when the hardware router from the other side responds, I get REJECT error on the shorewall. I dont understand why is shorewall rejecting local traffic. This is the message: Shorewall:all2all:REJECT:IN=eth0 OUTMAC=00:40:f4:b2:94:96:00:19:cb:2c:df:87:08:00 SRC=85.x.x.x DST=193.x.x.x LEN=104 TOS=0x00 PREC=0x00 TTL=245 ID=36536 PROTO=UDP SPT=500 DPT=500 LEN=84 There are external IP loged on the internal network. I dont get it. I have accept rules for all port and tcp, udp, ah and esp for NET:IP to FW and NET:IP to LOC. DNAT is created for NET:IP to LOC:IP for all ports and all protocols. Thanks for you hint and suggestions. Scorpy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Scorpy wrote:> Dsl0 – internet interface > Eth0 – local network > > I have linux box with shorewall 2.2.Which hasn''t been supported since Dec 1, 2005!> And on the local network I also > have a hardware router. I have connected WAN port with settings of my > linux boxWhat does that mean? Does in mean that you assigned an RFC 1918 address to the WAN port and set the router''s default gateway to the IP address of the internal interface on your linux box?> and then created one more local network behind hardware > router. It works fine. > > I then wanted to use VPN function of this hardware routerHopefully the router''s VPN supports NAT-T(Nat traversal) and you have configured the VPN to use it; otherwise, this probably won''t work at all).> so i created > ACCEPT and DNAT rules on shorewall so that all traffic is permited from > one external IP to this internat IP of hardware router.Did you add an SNAT rule (/etc/shorewall/masq) so that traffic from this router appears to come from that external IP address?> Now i know that the connection works fine if i try to send packets from > my hardware router to other side, but when the hardware router from the > other side responds, I get REJECT error on the shorewall.The traffic that is being logged is coming INTO your firewall on eth0 -- it isn''t a response from ''...the other side''.> I dont > understand why is shorewall rejecting local traffic.''detectnets'', maybe?> This is the message:> Shorewall:all2all:REJECT:IN=eth0 OUT> MAC=00:40:f4:b2:94:96:00:19:cb:2c:df:87:08:00 SRC=85.x.x.x DST=193.x.x.x > LEN=104 TOS=0x00 PREC=0x00 TTL=245 ID=36536 PROTO=UDP SPT=500 DPT=500 LEN=84 > > There are external IP loged on the internal network. I dont get it.I don''t either -- but then you really haven''t given us anything to go on (no Shorewall configuration or dump -- oh, Shorewall 2.2 didn''t even have a ''dump'' command. You really should upgrade....).> I have accept rules for all port and tcp, udp, ah and esp for NET:IP to > FW and NET:IP to LOC. > > DNAT is created for NET:IP to LOC:IP for all ports and all protocols.Again, what about SNAT? -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>What does that mean? Does in mean that you assigned an RFC 1918 address >to the WAN port and set the router''s default gateway to the IP address >of the internal interface on your linux box?Yes, that is correct.>Hopefully the router''s VPN supports NAT-T(Nat traversal) and you have >configured the VPN to use it; otherwise, this probably won''t work at all).Hmm dont know yet. I can see that the packets which i sent get to the other side. The problem is that the packets i recive dont reach the hw router on this side. I keep getting reject log on internal interface of linux box, for udp packets. The internet is working fine from this router.>Did you add an SNAT rule (/etc/shorewall/masq) so that traffic from this >router appears to come from that external IP address?Hmm. No i didnt. I just set DNAT rule in "rules" like this: DNAT net:$other_hw_router loc:local_ip_of_my_hw_router udp 500 Can you write me the code for "masq"? I dont get it, which external IP must appear. My HW router has internet address like "192.168.x.x" and when it send packet it uses linux box and its IP "193.x.x.x.". That IP is also visible on the other side of the internet on other HW router. At least it should be, because other hw router is set to alow only that IP (193.x.x.x).>The traffic that is being logged is coming INTO your firewall on eth0 -- >it isn''t a response from ''...the other side''.But why do I get reject error then? (85.x.x.x is the HW router on other side; 193.x.x.x. is the linux box) Shorewall:all2all:REJECT:IN=eth0 OUT> MAC=00:40:f4:b2:94:96:00:19:cb:2c:df:87:08:00 SRC=85.x.x.x DST=193.x.x.x> LEN=104 TOS=0x00 PREC=0x00 TTL=245 ID=36536 PROTO=UDP SPT=500 DPT=500LEN=84>I don''t either -- but then you really haven''t given us anything to go on >(no Shorewall configuration or dump -- oh, Shorewall 2.2 didn''t even >have a ''dump'' command. You really should upgrade....).> I have accept rules for all port and tcp, udp, ah and esp for NET:IP to > FW and NET:IP to LOC. > > DNAT is created for NET:IP to LOC:IP for all ports and all protocols.>Again, what about SNAT?Hmmm. Not sure what you are trying to say. Do you mean what you mentioned above about "masq"? I know this kind of questions are stupid, but please give me more hints. Thanks! Scorpy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Scorpy wrote:> >> What does that mean? Does in mean that you assigned an RFC 1918 address >> to the WAN port and set the router''s default gateway to the IP address >> of the internal interface on your linux box? > > Yes, that is correct. > >> Hopefully the router''s VPN supports NAT-T(Nat traversal) and you have >> configured the VPN to use it; otherwise, this probably won''t work at all). > > Hmm dont know yet.Since you are NATing the connection, you should only be DNATing UDP port 500 and 4500 to the internal router for VPN traffic. Again, there is very little chance if it working without NAT-T. The two IPSEC endpoints will determine that there is at least one NAT router between them and will encapsulate the ESP packets in UDP 4500 packets. AH cannot be used in this configuration.> I can see that the packets which i sent get to the other > side. The problem is that the packets i recive dont reach the hw router on > this side. I keep getting reject log on internal interface of linux box, for > udp packets.And on the INTERNAL interface? If so, it sounds like your internal and external interfaces are somehow bridged.> The internet is working fine from this router. > >> Did you add an SNAT rule (/etc/shorewall/masq) so that traffic from this >> router appears to come from that external IP address? > > Hmm. No i didnt. I just set DNAT rule in "rules" like this: > DNAT net:$other_hw_router loc:local_ip_of_my_hw_router udp 500 > > Can you write me the code for "masq"?Do you only have one external IP address (193.x.x.x)? If so, your existing MASQ/SNAT entry in /etc/shorewall/masq is all you need.>> The traffic that is being logged is coming INTO your firewall on eth0 -- >> it isn''t a response from ''...the other side''. > > But why do I get reject error then? (85.x.x.x is the HW router on other > side; 193.x.x.x. is the linux box) >How could we possibly know? We can''t see your ruleset. And you are so tight-fisted with details, you won'' even tell us what your external IP address is (even though everyone on the list already knows what it is and could care less). Shorewall 2.2 supports a "shorewall status" command -- if you send us the output of that command (as a compressed attachment), it will help although the information in that command is not nearly so complete and helpful as the output of "shorewall dump" in later versions. My guess is that you have ''detectnets'' specified on eth0 in /etc/shorewall/interfaces so that packets from 85.x.x.x aren''t in the ''loc'' zone (see Shorewall FAQ 17).> Shorewall:all2all:REJECT:IN=eth0 OUT>> MAC=00:40:f4:b2:94:96:00:19:cb:2c:df:87:08:00 SRC=85.x.x.x DST=193.x.x.x >> LEN=104 TOS=0x00 PREC=0x00 TTL=245 ID=36536 PROTO=UDP SPT=500 DPT=500 > LEN=84 >But that still begs the question about why the above packet is showing up on your internal interface in the first place -- it should be arriving on your internal interface). Again, it looks to me kind your internal and external interfaces may be bridged. What is the sequence of packets that you are seeing? Is it: 1) internal router->remote router UDP 500 2) <message above> Or do you see packets (including ESP) go back and forth and THEN you get the message? -Tom> >> I don''t either -- but then you really haven''t given us anything to go on >> (no Shorewall configuration or dump -- oh, Shorewall 2.2 didn''t even >> have a ''dump'' command. You really should upgrade....). > >> I have accept rules for all port and tcp, udp, ah and esp for NET:IP to >> FW and NET:IP to LOC.ACCEPT rules from net->fw are not required here. And the NET->LOC rules must be DNAT rules.>> >> DNAT is created for NET:IP to LOC:IP for all ports and all protocols. > >> Again, what about SNAT? > > Hmmm. Not sure what you are trying to say. Do you mean what you mentioned > above about "masq"? I know this kind of questions are stupid, but please > give me more hints.Again, if you only have one external IP address then you already have the necessary entry in /etc/shorewall/masq. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> > But that still begs the question about why the above packet is showing > up on your internal interface in the first place -- it should be > arriving on your internal interface).I of course meant to write "...should be arriving on your *external* interface". -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Sending again without attachment. I dont get mail on the list if i send the attachment.>Since you are NATing the connection, you should only be DNATing UDP port >500 and 4500 to the internal router for VPN traffic. Again, there is >very little chance if it working without NAT-T. The two IPSEC endpoints >will determine that there is at least one NAT router between them and >will encapsulate the ESP packets in UDP 4500 packets. AH cannot be used >in this configuration.The hw router is sending information only on udp port 500. I can see this, because only this port is blocked on linux box.> I can see that the packets which i sent get to the other > side. The problem is that the packets i recive dont reach the hw router on > this side. I keep getting reject log on internal interface of linux box,for> udp packets.>And on the INTERNAL interface? If so, it sounds like your internal and >external interfaces are somehow bridged.Hmm. I didnt used any bridge settings. I have one ADSL (pppoe) and one internet interface. All i do is DNAT as i mentioned before.> The internet is working fine from this router. > >> Did you add an SNAT rule (/etc/shorewall/masq) so that traffic from this >> router appears to come from that external IP address? > > Hmm. No i didnt. I just set DNAT rule in "rules" like this: > DNAT net:$other_hw_router loc:local_ip_of_my_hw_router udp500> > Can you write me the code for "masq"?>Do you only have one external IP address (193.x.x.x)? If so, your >existing MASQ/SNAT entry in /etc/shorewall/masq is all you need.Yes. O only have one external IP. And i have already entry for this in masq.>> The traffic that is being logged is coming INTO your firewall on eth0 -- >> it isn''t a response from ''...the other side''. > > But why do I get reject error then? (85.x.x.x is the HW router on other > side; 193.x.x.x. is the linux box) > >How could we possibly know? We can''t see your ruleset. And you are so >tight-fisted with details, you won'' even tell us what your external IP >address is (even though everyone on the list already knows what it is >and could care less). Shorewall 2.2 supports a "shorewall status" >command -- if you send us the output of that command (as a compressed >attachment), it will help although the information in that command is >not nearly so complete and helpful as the output of "shorewall dump" in >later versions.Ok. I attached the file status. The IP with the linux box is 193.95.229.95 and not the IP located in my mail (i know you can see my IP). The hw router has internat IP 192.168.1.180. On the other side the hw router has IP 85.10.34.99. Both hw routers are Zyxel Zywall 2 plus.>My guess is that you have ''detectnets'' specified on eth0 in >/etc/shorewall/interfaces so that packets from 85.x.x.x aren''t in the >''loc'' zone (see Shorewall FAQ 17).No, i only use this settings. I also used routeback on eth0 and no diference. #ZONE INTERFACE BROADCAST OPTIONS net dsl0 detect routefilter,tcpflags loc eth0 detect tcpflags> Shorewall:all2all:REJECT:IN=eth0 OUT>> MAC=00:40:f4:b2:94:96:00:19:cb:2c:df:87:08:00 SRC=85.x.x.x DST=193.x.x.x >> LEN=104 TOS=0x00 PREC=0x00 TTL=245 ID=36536 PROTO=UDP SPT=500 DPT=500 > LEN=84 >>But that still begs the question about why the above packet is showing >up on your internal interface in the first place -- it should be >arriving on your internal interface).>Again, it looks to me kind your internal and external interfaces may be >bridged.>What is the sequence of packets that you are seeing? Is it:> 1) internal router->remote router UDP 500 > 2) <message above>>Or do you see packets (including ESP) go back and forth and THEN you get >the message?Yes. I can see message go forth to other side and when the hw router on the other side responds and send response, the linux box on my side blocks the UDP port 500. Scopry. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Scorpy wrote:> Sending again without attachment. I dont get mail on the list if i send the > attachment.Did you compress the attachment? The list has a maximum attachment size.> >> Since you are NATing the connection, you should only be DNATing UDP port >> 500 and 4500 to the internal router for VPN traffic. Again, there is >> very little chance if it working without NAT-T. The two IPSEC endpoints >> will determine that there is at least one NAT router between them and >> will encapsulate the ESP packets in UDP 4500 packets. AH cannot be used >> in this configuration. > > The hw router is sending information only on udp port 500. I can see this, > because only this port is blocked on linux box.That''s very shaky logic. Have you LOOKED at the traffic with a traffic sniffer like tcpdump or Wireshark?> Yes. I can see message go forth to other side and when the hw router on the > other side responds and send response, the linux box on my side blocks the > UDP port 500.Once more -- the packet that is getting blocked is coming from your internal network and it is addressed to your firewall!!! So if your external and internal interfaces aren''t bridged then the packet must be coming from the Zyxel in your local network. Try this test: a) from your Shorewall box, ping 192.168.1.180 (The Zyxel). b) type "arp -na". Is 00:40:f4:b2:94:96 the MAC address associated with 192.168.1.180 in the output from ''arp''? -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> Scorpy wrote: >> Sending again without attachment. I dont get mail on the list if i send the >> attachment. > > Did you compress the attachment? The list has a maximum attachment size.You can also send it to support@shorewall.net. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>Did you compress the attachment? The list has a maximum attachment size.Yes I did (ZIP format - 32KB). I also checked and my hw router supports NAT-T which is enabled.>>That''s very shaky logic. Have you LOOKED at the traffic with a traffic >sniffer like tcpdump or Wireshark?Yes. I used tcpdump.>Once more -- the packet that is getting blocked is coming from your >internal network and it is addressed to your firewall!!!>So if your external and internal interfaces aren''t bridged then the >packet must be coming from the Zyxel in your local network.>Try this test:>a) from your Shorewall box, ping 192.168.1.180 (The Zyxel). >b) type "arp -na".>Is 00:40:f4:b2:94:96 the MAC address associated with 192.168.1.180 in >the output from ''arp''?No. I get different MAC. (00:19:CB:2C:DF:87) So the MAC mentioned above must be from hw router from other side. Scorpy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Ok. I have sent the log to support support@shorewall.net Scorpy -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, January 17, 2008 10:16 PM To: Shorewall Users Subject: Re: [Shorewall-users] Local network rejecting traffic Tom Eastep wrote:> Scorpy wrote: >> Sending again without attachment. I dont get mail on the list if i sendthe>> attachment. > > Did you compress the attachment? The list has a maximum attachment size.You can also send it to support@shorewall.net. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Maybe this will help. I used tcpdump at the same time on dsl0 and eth0. ETH0 (local) 22:38:16.155954 IP 192.168.1.180.isakmp > cpe-85-10-34-99.static.amis.net.isakmp: isakmp: phase 1 I agg 22:38:16.893540 IP cpe-85-10-34-99.static.amis.net.isakmp > 192.168.1.180.isakmp: isakmp: phase 1 R agg 22:38:16.894071 IP cpe-85-10-34-99.static.amis.net.isakmp > BSN-95-229-95.dsl.siol.net.isakmp: isakmp: phase 1 R agg DSL0 (internet) 22:38:16.156082 IP BSN-95-229-95.dsl.siol.net.tcpmux > cpe-85-10-34-99.static.amis.net.isakmp: isakmp: phase 1 I agg 22:38:16.893450 IP cpe-85-10-34-99.static.amis.net.isakmp > BSN-95-229-95.dsl.siol.net.tcpmux: isakmp: phase 1 R agg 22:38:16.894409 IP BSN-95-229-95.dsl.siol.net > cpe-85-10-34-99.static.amis.net: icmp 432: BSN-95-229-95.dsl.siol.net udp port isakmp unreachable I couldnt get the error at the same time, but its always the same like this: Jan 17 22:36:14 contraco kernel: Shorewall:all2all:REJECT:IN=eth0 OUTMAC=00:40:f4:b2:94:96:00:19:cb:2c:df:87:08:00 SRC=85.10.34.99 DST=193.95.229.95 LEN=424 TOS=0x00 PREC=0x00 TTL=245 ID=44292 PROTO=UDP SPT=500 DPT=500 LEN=404 Any ideas? Scorpy -----Original Message----- From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, January 17, 2008 10:16 PM To: Shorewall Users Subject: Re: [Shorewall-users] Local network rejecting traffic Tom Eastep wrote:> Scorpy wrote: >> Sending again without attachment. I dont get mail on the list if i sendthe>> attachment. > > Did you compress the attachment? The list has a maximum attachment size.You can also send it to support@shorewall.net. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Scorpy wrote:>> Did you compress the attachment? The list has a maximum attachment size. > > Yes I did (ZIP format - 32KB). > I also checked and my hw router supports NAT-T which is enabled. > > >> That''s very shaky logic. Have you LOOKED at the traffic with a traffic >> sniffer like tcpdump or Wireshark? > > Yes. I used tcpdump. > > >> Once more -- the packet that is getting blocked is coming from your >> internal network and it is addressed to your firewall!!! > >> So if your external and internal interfaces aren''t bridged then the >> packet must be coming from the Zyxel in your local network. > >> Try this test: > >> a) from your Shorewall box, ping 192.168.1.180 (The Zyxel). >> b) type "arp -na". > >> Is 00:40:f4:b2:94:96 the MAC address associated with 192.168.1.180 in >> the output from ''arp''? > > No. I get different MAC. (00:19:CB:2C:DF:87)Sorry -- I picked the wrong field out of the MAC address in the ''Shorewall'' message. Here''s from the message: IN=eth0 OUT= MAC=00:40:f4:b2:94:96:00:19:cb:2c:df:87:08:00 The incoming interface is eth0. There is no outgoing interface when means that the packet is addressed to the Shorewall box. The link layer address of the recipient is 00:40:f4:b2:94:96 which I assume is the MAC address of eth0. 00:19:cb:2c:df:87 is the MAC address of the sender (the ZyXEL). 08:00 is the ethernet frame type (IPv4).> So the MAC mentioned above must be from hw router from other side. >No. The ZyXEL behind your firewall is sending the packet that is getting rejected! The Shorewall-generated ruleset is rejecting the packet because the only connections that you allow from the local net to the firewall are ping and SSH (I just got the ''status'' output). I don''t know why your interior router is sending that packet. I can only guess that the two IPSEC endpoints are failing to recognize that NAT is taking place (is the router at the other end configured for NAT-T?) so they negotiate an SA without it. Once an SA is negotiated, ISAKMP (UDP 500) packets can be sent through the encrypted tunnel if the SA involves both endpoints. When your internal router gets the first of these (which has not undergone DNAT) it of course doesn''t recognize that the packet is really meant for it so it does what routers do -- it forward the packet to its default gateway (your firewall). -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Scorpy wrote:> Maybe this will help. > I used tcpdump at the same time on dsl0 and eth0. > > ETH0 (local) > 22:38:16.155954 IP 192.168.1.180.isakmp > > cpe-85-10-34-99.static.amis.net.isakmp: isakmp: phase 1 I agg > 22:38:16.893540 IP cpe-85-10-34-99.static.amis.net.isakmp > > 192.168.1.180.isakmp: isakmp: phase 1 R agg > 22:38:16.894071 IP cpe-85-10-34-99.static.amis.net.isakmp > > BSN-95-229-95.dsl.siol.net.isakmp: isakmp: phase 1 R aggOkay -- this is interesting. The local router is clearly confused; I suspect as a result of NAT taking place between the two routers. It is sending an ISAKMP phase 1 R packet addressed to your firewall and with a source IP of the remote router (which is what we''ve been seeing in the Shorewall message). So the two routers don''t get so far as to negotiate an SA; the local one sends an unfathomable (to me) packet. Afraid that you have reached the end of my knowledge here but I suspect that it is a configuration problem in one or both of the routers. Maybe someone more familiar with ISAKMP can shed some light. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>Sorry -- I picked the wrong field out of the MAC address in the >''Shorewall'' message.Yes your are right. One MAC is from ETH0, other from my hw router.>The Shorewall-generated ruleset is rejecting the packet because the only >connections that you allow from the local net to the firewall are ping >and SSH (I just got the ''status'' output).I now allow also UDP. I dont get any error on shorewall report logs. But it still doesnt work. Both routers use NAT-T.>I don''t know why your interior router is sending that packet. I can only >guess that the two IPSEC endpoints are failing to recognize that NAT is >taking place (is the router at the other end configured for NAT-T?) so >they negotiate an SA without it. Once an SA is negotiated, ISAKMP (UDP >500) packets can be sent through the encrypted tunnel if the SA involves >both endpoints. When your internal router gets the first of these (which >has not undergone DNAT) it of course doesn''t recognize that the packet >is really meant for it so it does what routers do -- it forward the >packet to its default gateway (your firewall).Can you suggest anything I cant do/test? Did you recive tcpdump in my mail (for ETH0 and DSL0) ? Scorpy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>Okay -- this is interesting. The local router is clearly confused; I >suspect as a result of NAT taking place between the two routers. It is >sending an ISAKMP phase 1 R packet addressed to your firewall and with a >source IP of the remote router (which is what we''ve been seeing in the >Shorewall message).>So the two routers don''t get so far as to negotiate an SA; the local one >sends an unfathomable (to me) packet.>Afraid that you have reached the end of my knowledge here but I suspect >that it is a configuration problem in one or both of the routers. Maybe >someone more familiar with ISAKMP can shed some light.Is it posible to solve this problem to tell router where to send packets with some static route? Or is there some options in shorewall maybe i can use? Scorpy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Scorpy wrote:>> Okay -- this is interesting. The local router is clearly confused; I >> suspect as a result of NAT taking place between the two routers. It is >> sending an ISAKMP phase 1 R packet addressed to your firewall and with a >> source IP of the remote router (which is what we''ve been seeing in the >> Shorewall message). > >> So the two routers don''t get so far as to negotiate an SA; the local one >> sends an unfathomable (to me) packet. > >> Afraid that you have reached the end of my knowledge here but I suspect >> that it is a configuration problem in one or both of the routers. Maybe >> someone more familiar with ISAKMP can shed some light. > > Is it posible to solve this problem to tell router where to send packets > with some static route? Or is there some options in shorewall maybe i can > use?I don''t know -- I don''t know why the ZyXEL router is doing what it is doing so I have no idea how to fix it. One thing I notice is that your DNAT rule for UDP 500 is wrong. It appears to have 192.168.1.180 in the ORIGINAL DEST column; you should either leave that blank or you should have 193.95.229.95 in that column. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Thu, Jan 17, 2008 at 03:01:37PM -0800, Tom Eastep wrote:> Scorpy wrote: > >> Okay -- this is interesting. The local router is clearly confused; I > >> suspect as a result of NAT taking place between the two routers. It is > >> sending an ISAKMP phase 1 R packet addressed to your firewall and with a > >> source IP of the remote router (which is what we''ve been seeing in the > >> Shorewall message). > > > >> So the two routers don''t get so far as to negotiate an SA; the local one > >> sends an unfathomable (to me) packet. > > > >> Afraid that you have reached the end of my knowledge here but I suspect > >> that it is a configuration problem in one or both of the routers. Maybe > >> someone more familiar with ISAKMP can shed some light. > > > > Is it posible to solve this problem to tell router where to send packets > > with some static route? Or is there some options in shorewall maybe i can > > use? > > I don''t know -- I don''t know why the ZyXEL router is doing what it is > doing so I have no idea how to fix it.My experience of zyxel devices in connection with ipsec is that they are buggy and shipped in a misconfigured state. My solution to date has always been to stop using ipsec (usually switching to openvpn) because I couldn''t figure out how to get them working, and suspected that the manufacturer had never bothered to test them. Note that ISAKMP is an extremely fragile protocol: if any part of the packets is not precisely as expected, the hosts will simply give up. This is a (questionable) design decision; there is no negotiation mechanism. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/