Hi all, I am running shorewall-3.2.4-5 on Fedora Core 5 2.6.17-1.2174. My problem is this: When I ping an external IP address the replies return but one is addressed to my external interface and one to the internal address that sent the ping. This occurs from anything in the vlan2 or svpn zone. I can ping normally from firewall. captured with tshark: 0.000000 150.101.x.x -> 150.101.1.1 ICMP Echo (ping) request 0.017010 150.101.1.1 -> 150.101.x.x ICMP Echo (ping) reply 0.017155 150.101.1.1 -> 192.168.0.210 ICMP Echo (ping) reply I have two providers, one on eth1 and one on eth2. My internal network is on eth0 but has serveral vlans attached to it. One of those vlans has a sub zone for internal vpns machines. /etc/shorewall/interfaces: aapt eth2 192.168.3.255 tcpflags,routefilter,blacklist,nosmurfs,logmartians intn eth1 150.101.x.x routeback,tcpflags,routefilter,norfc1918,blacklist,nosmurfs,logmartians vlan2 vlan2 detect routeback vlan3 vlan3 detect routeback vpn vlan4 detect routeback wifi vlan5 detect routeback /etc/shorewall/masq eth1 vlan2 eth2 vlan2 eth1 vlan3 eth2 vlan3 eth1 vlan4 eth2 vlan4 eth1 vlan5 eth2 vlan5 /etc/shorewall/zones fw firewall vlan2 ipv4 # office vlan3 ipv4 # dmz vpn ipsec mss=1400 # VPN zone for external clients - vlan4 wifi ipv4 # wifi zone - vlan5 aapt ipv4 intn ipv4 svpn:vlan2 ipsec mss=1400 # ipsec zone for clients in vlan2 /etc/shorewall/hosts svpn vlan2:192.168.0.30,192.168.0.130 ipsec /etc/shorewall/policy aapt all REJECT info intn all REJECT info vlan2 all REJECT DEBUG svpn all REJECT DEBUG vlan3 all DROP info $FW all DROP info all all DROP /etc/shorewall/rules # Firewall to anywhere Ping/ACCEPT:DEBUG $FW all Trcrt/ACCEPT:DEBUG $FW all DNS/ACCEPT $FW all NTP/ACCEPT $FW all UIPSEC/ACCEPT $FW vlan2 #UWEB/ACCEPT $FW svpn # Anywhere to Firewall Ping/ACCEPT:DEBUG all $FW Trcrt/ACCEPT:DEBUG all $FW DNS/ACCEPT all $FW #SSH/ACCEPT svpn $FW SSH/ACCEPT vlan2 $FW UNTP/ACCEPT vlan2 $FW UNTP/ACCEPT vlan3 $FW UNTP/ACCEPT vpn $FW UNTP/ACCEPT wifi $FW UIPSEC/ACCEPT vlan2 $FW # vlan2 (office) to internet Ping/ACCEPT:DEBUG vlan2 aapt Trcrt/ACCEPT:DEBUG vlan2 aapt USSH/ACCEPT vlan2 aapt # UWEB/ACCEPT vlan2 aapt # UCHAT/ACCEPT vlan2 aapt # Ping/ACCEPT vlan2 intn Trcrt/ACCEPT:DEBUG vlan2 intn USSH/ACCEPT vlan2 intn UWEB/ACCEPT vlan2 intn UCHAT/ACCEPT vlan2 intn URADIO/ACCEPT vlan2 intn logging in kernel.log shows: Jan 4 10:17:16 gw1 kernel: Shorewall:mangle:PREROUTING:IN=vlan2 OUTMAC=00:11:95:c7:13:03:00:0b:db:09:93:da:08:00:45:00:00:54 SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 Jan 4 10:17:16 gw1 kernel: Shorewall:nat:PREROUTING:IN=vlan2 OUTMAC=00:11:95:c7:13:03:00:0b:db:09:93:da:08:00:45:00:00:54 SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 Jan 4 10:17:16 gw1 kernel: Shorewall:mangle:FORWARD:IN=vlan2 OUT=eth1 SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 Jan 4 10:17:16 gw1 kernel: Shorewall:filter:FORWARD:IN=vlan2 OUT=eth1 SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 Jan 4 10:17:16 gw1 kernel: Shorewall:mangle:POSTROUTING:IN= OUT=eth1 SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 Jan 4 10:17:16 gw1 kernel: Shorewall:nat:POSTROUTING:IN= OUT=eth1 SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 Which bit is wrong? Thanks, Denmat ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi, since the usually lightning-fast Tom hasn''t answered yet, let me ask the obligatory ''please follow the support guidelines on shorewall.net'' (i.e. provide a shorewall dump while pinging, but please read the doc for full info). Someone might help with what you provided, but if not there''ll be a much better of that than now where you only made parts of your config available. ~David On 1/4/07, denmat <tu2bgone@gmail.com> wrote:> Hi all, > > I am running shorewall-3.2.4-5 on Fedora Core 5 2.6.17-1.2174. > > My problem is this: > When I ping an external IP address the replies return but one is > addressed to my external interface and one to the internal address > that sent the ping. This occurs from anything in the vlan2 or svpn > zone. I can ping normally from firewall. > > captured with tshark: > 0.000000 150.101.x.x -> 150.101.1.1 ICMP Echo (ping) request > 0.017010 150.101.1.1 -> 150.101.x.x ICMP Echo (ping) reply > 0.017155 150.101.1.1 -> 192.168.0.210 ICMP Echo (ping) reply > > I have two providers, one on eth1 and one on eth2. My internal network > is on eth0 but has serveral vlans attached to it. One of those vlans > has a sub zone for internal vpns machines. > > /etc/shorewall/interfaces: > aapt eth2 192.168.3.255 > tcpflags,routefilter,blacklist,nosmurfs,logmartians > intn eth1 150.101.x.x > routeback,tcpflags,routefilter,norfc1918,blacklist,nosmurfs,logmartians > vlan2 vlan2 detect routeback > vlan3 vlan3 detect routeback > vpn vlan4 detect routeback > wifi vlan5 detect routeback > > /etc/shorewall/masq > eth1 vlan2 > eth2 vlan2 > eth1 vlan3 > eth2 vlan3 > eth1 vlan4 > eth2 vlan4 > eth1 vlan5 > eth2 vlan5 > > /etc/shorewall/zones > fw firewall > vlan2 ipv4 # office > vlan3 ipv4 # dmz > vpn ipsec mss=1400 # VPN zone for > external clients - vlan4 > wifi ipv4 # wifi zone - vlan5 > aapt ipv4 > intn ipv4 > svpn:vlan2 ipsec mss=1400 # ipsec zone for clients in vlan2 > > /etc/shorewall/hosts > svpn vlan2:192.168.0.30,192.168.0.130 ipsec > > /etc/shorewall/policy > aapt all REJECT info > intn all REJECT info > vlan2 all REJECT DEBUG > svpn all REJECT DEBUG > vlan3 all DROP info > $FW all DROP info > all all DROP > > /etc/shorewall/rules > # Firewall to anywhere > Ping/ACCEPT:DEBUG $FW all > Trcrt/ACCEPT:DEBUG $FW all > DNS/ACCEPT $FW all > NTP/ACCEPT $FW all > UIPSEC/ACCEPT $FW vlan2 > #UWEB/ACCEPT $FW svpn > > # Anywhere to Firewall > Ping/ACCEPT:DEBUG all $FW > Trcrt/ACCEPT:DEBUG all $FW > DNS/ACCEPT all $FW > #SSH/ACCEPT svpn $FW > SSH/ACCEPT vlan2 $FW > UNTP/ACCEPT vlan2 $FW > UNTP/ACCEPT vlan3 $FW > UNTP/ACCEPT vpn $FW > UNTP/ACCEPT wifi $FW > UIPSEC/ACCEPT vlan2 $FW > > > # vlan2 (office) to internet > Ping/ACCEPT:DEBUG vlan2 aapt > Trcrt/ACCEPT:DEBUG vlan2 aapt > USSH/ACCEPT vlan2 aapt # > UWEB/ACCEPT vlan2 aapt # > UCHAT/ACCEPT vlan2 aapt # > Ping/ACCEPT vlan2 intn > Trcrt/ACCEPT:DEBUG vlan2 intn > USSH/ACCEPT vlan2 intn > UWEB/ACCEPT vlan2 intn > UCHAT/ACCEPT vlan2 intn > URADIO/ACCEPT vlan2 intn > > logging in kernel.log shows: > Jan 4 10:17:16 gw1 kernel: Shorewall:mangle:PREROUTING:IN=vlan2 OUT> MAC=00:11:95:c7:13:03:00:0b:db:09:93:da:08:00:45:00:00:54 > SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 > ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 > Jan 4 10:17:16 gw1 kernel: Shorewall:nat:PREROUTING:IN=vlan2 OUT> MAC=00:11:95:c7:13:03:00:0b:db:09:93:da:08:00:45:00:00:54 > SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 > ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 > Jan 4 10:17:16 gw1 kernel: Shorewall:mangle:FORWARD:IN=vlan2 OUT=eth1 > SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 > ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 > Jan 4 10:17:16 gw1 kernel: Shorewall:filter:FORWARD:IN=vlan2 OUT=eth1 > SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 > ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 > Jan 4 10:17:16 gw1 kernel: Shorewall:mangle:POSTROUTING:IN= OUT=eth1 > SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 > ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 > Jan 4 10:17:16 gw1 kernel: Shorewall:nat:POSTROUTING:IN= OUT=eth1 > SRC=192.168.0.210 DST=150.101.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 > ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=11539 SEQ=1 > > Which bit is wrong? > > Thanks, > > Denmat > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
David Mohr wrote:> Hi, > since the usually lightning-fast Tom hasn''t answered yet, let me ask > the obligatory ''please follow the support guidelines on shorewall.net'' > (i.e. provide a shorewall dump while pinging, but please read the doc > for full info). Someone might help with what you provided, but if not > there''ll be a much better of that than now where you only made parts > of your config available.The " usually lightning-fast Tom" saw the report but: a) It doesn''t report a problem but rather reports a symptom (a packet trace shows both pre-NAT and post-NAT packets). b) The poster didn''t mention which interface(s) the trace was obtained from. If the trace is from one interface then it looks like it could be a VLAN configuration problem. Otherwise, it could even be normal and not related to whatever problem the poster has. There might be something Shorewall-related there but I rather doubt it. Without the required documentation and without even a problem definition, I just ignored the report. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Hi, I''m very sorry about not posting the correct way, and thanks for
your replies.
I have attached the shorewall dump and the tshark trace below was
captured on the external interface of the firewall.
Here also is ip addr show:
1: lo: <LOOPBACK,UP,10000> 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: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 7000 qdisc pfifo_fast qlen
1000
link/ether 00:11:95:c7:13:03 brd ff:ff:ff:ff:ff:ff
inet6 fe80::211:95ff:fec7:1303/64 scope link
valid_lft forever preferred_lft forever
3: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
link/ether 00:02:a5:76:06:7b brd ff:ff:ff:ff:ff:ff
inet 192.168.3.2/24 brd 192.168.3.255 scope global eth2
inet6 fe80::202:a5ff:fe76:67b/64 scope link
valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
link/ether 00:0e:0c:9c:3a:fb brd ff:ff:ff:ff:ff:ff
inet 150.101.158.86/29 brd 150.101.158.87 scope global eth1
inet6 fe80::20e:cff:fe9c:3afb/64 scope link
valid_lft forever preferred_lft forever
5: vlan2@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 7000 qdisc noqueue
link/ether 00:11:95:c7:13:03 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.181/24 brd 192.168.0.255 scope global vlan2
inet6 fe80::211:95ff:fec7:1303/64 scope link
valid_lft forever preferred_lft forever
6: vlan3@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 7000 qdisc noqueue
link/ether 00:11:95:c7:13:03 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.181/24 brd 192.168.1.255 scope global vlan3
inet6 fe80::211:95ff:fec7:1303/64 scope link
valid_lft forever preferred_lft forever
7: vlan4@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 7000 qdisc noqueue
link/ether 00:11:95:c7:13:03 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.181/29 brd 192.168.10.183 scope global vlan4
inet6 fe80::211:95ff:fec7:1303/64 scope link
valid_lft forever preferred_lft forever
8: vlan5@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 7000 qdisc noqueue
link/ether 00:11:95:c7:13:03 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.181/24 brd 192.168.11.255 scope global vlan5
inet6 fe80::211:95ff:fec7:1303/64 scope link
valid_lft forever preferred_lft forever
9: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
and here is ip route show:
150.101.158.80/29 dev eth1 proto kernel scope link src 150.101.158.86
192.168.10.176/29 dev vlan4 proto kernel scope link src 192.168.10.181
192.168.3.0/24 dev eth2 proto kernel scope link src 192.168.3.2
192.168.1.0/24 dev vlan3 proto kernel scope link src 192.168.1.181
192.168.0.0/24 dev vlan2 proto kernel scope link src 192.168.0.181
192.168.11.0/24 dev vlan5 proto kernel scope link src 192.168.11.181
169.254.0.0/16 dev vlan5 scope link
default
nexthop via 192.168.3.1 dev eth2 weight 1
nexthop via 150.101.158.81 dev eth1 weight 1
Actual ping is from 192.168.0.210 (vlan2) to 150.101.1.1 (out eth1 to
ISP router).
Regards,
Denmat
On 1/5/07, Tom Eastep <teastep@shorewall.net>
wrote:> David Mohr wrote:
> > Hi,
> > since the usually lightning-fast Tom hasn''t answered yet, let
me ask
> > the obligatory ''please follow the support guidelines on
shorewall.net''
> > (i.e. provide a shorewall dump while pinging, but please read the doc
> > for full info). Someone might help with what you provided, but if not
> > there''ll be a much better of that than now where you only
made parts
> > of your config available.
>
> The " usually lightning-fast Tom" saw the report but:
>
> a) It doesn''t report a problem but rather reports a symptom (a
packet
> trace shows both pre-NAT and post-NAT packets).
> b) The poster didn''t mention which interface(s) the trace was
obtained from.
>
> If the trace is from one interface then it looks like it could be a VLAN
> configuration problem. Otherwise, it could even be normal and not
> related to whatever problem the poster has.
>
> There might be something Shorewall-related there but I rather doubt it.
> Without the required documentation and without even a problem
> definition, I just ignored the report.
>
> -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
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net''s Techsay panel and you''ll get the
chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net''s Techsay panel and you''ll get the chance
to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
denmat wrote:> Hi, I''m very sorry about not posting the correct way, and thanks for > your replies. > > I have attached the shorewall dump and the tshark trace below was > captured on the external interface of the firewall.Shorewall isn''t even running when that dump was taken!> 5: vlan2@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 7000 qdisc noqueue > link/ether 00:11:95:c7:13:03 brd ff:ff:ff:ff:ff:ff > inet 192.168.0.181/24 brd 192.168.0.255 scope global vlan2 > inet6 fe80::211:95ff:fec7:1303/64 scope link > valid_lft forever preferred_lft foreverAs far as I know, Shorewall doesn''t support this form of vlan naming. I have added no support for it and I doubt that it just works by magic given that Shorewall parses the output of ''ip addr ls''. You must use the eth0.n variation. Please confirm that Shorewall can start successfully with this configuration. And if it can, I would love to see a trace (shorewall trace [re]start > trace.txt). 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> denmat wrote: > >> 5: vlan2@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 7000 qdisc noqueue >> link/ether 00:11:95:c7:13:03 brd ff:ff:ff:ff:ff:ff >> inet 192.168.0.181/24 brd 192.168.0.255 scope global vlan2 >> inet6 fe80::211:95ff:fec7:1303/64 scope link >> valid_lft forever preferred_lft forever > > As far as I know, Shorewall doesn''t support this form of vlan naming. I have > added no support for it and I doubt that it just works by magic given that > Shorewall parses the output of ''ip addr ls''. You must use the eth0.n variation. > > Please confirm that Shorewall can start successfully with this > configuration. And if it can, I would love to see a trace (shorewall trace > [re]start > trace.txt).My apologies. Looks like I did add support for that flavor of naming after all (they say the mind/memory is the first to go). -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> Tom Eastep wrote: >> denmat wrote: >> >>> 5: vlan2@eth0: <BROADCAST,MULTICAST,UP,10000> mtu 7000 qdisc noqueue >>> link/ether 00:11:95:c7:13:03 brd ff:ff:ff:ff:ff:ff >>> inet 192.168.0.181/24 brd 192.168.0.255 scope global vlan2 >>> inet6 fe80::211:95ff:fec7:1303/64 scope link >>> valid_lft forever preferred_lft forever >> As far as I know, Shorewall doesn''t support this form of vlan naming. I have >> added no support for it and I doubt that it just works by magic given that >> Shorewall parses the output of ''ip addr ls''. You must use the eth0.n variation. >> >> Please confirm that Shorewall can start successfully with this >> configuration. And if it can, I would love to see a trace (shorewall trace >> [re]start > trace.txt). > > My apologies. Looks like I did add support for that flavor of naming after > all (they say the mind/memory is the first to go).Groan -- I was correct the first time. Shorewall could handle interface names beginning with "@" but it can''t handle them with embedded "@". -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
denmat wrote:> Hi, I''m very sorry about not posting the correct way, and thanks for > your replies. > > I have attached the shorewall dump and the tshark trace below was > captured on the external interface of the firewall.Then I think that you need to look at the link-layer (MAC) source address of the extra packet (the one addresses to 192.168.0.210). I suspect that it will be 00:11:95:c7:13:03. -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> denmat wrote: >> Hi, I''m very sorry about not posting the correct way, and thanks for >> your replies. >> >> I have attached the shorewall dump and the tshark trace below was >> captured on the external interface of the firewall. > > Then I think that you need to look at the link-layer (MAC) source address of > the extra packet (the one addresses to 192.168.0.210). I suspect that it > will be 00:11:95:c7:13:03. >If it turns out to be some other MAC address (like whichever interface you call you are calling your ''external'' one[1]), then I need to see a dump with Shorewall started. It could be that you are using ''track'' in /etc/shorewall/interfaces and don''t have the internal interfaces listed properly in the COPY column. This would cause the packet to 192.168.0.210 to be send out of the wrong interface. -Tom [1] - The dump shows policy routing with two default gateways. So ''external interface'' isn''t completely clear. -- 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Tom Eastep wrote:> Tom Eastep wrote: >> denmat wrote: >>> Hi, I''m very sorry about not posting the correct way, and thanks for >>> your replies. >>> >>> I have attached the shorewall dump and the tshark trace below was >>> captured on the external interface of the firewall. >> Then I think that you need to look at the link-layer (MAC) source address of >> the extra packet (the one addresses to 192.168.0.210). I suspect that it >> will be 00:11:95:c7:13:03. >> > > If it turns out to be some other MAC address (like whichever interface you > call you are calling your ''external'' one[1]), then I need to see a dump with > Shorewall started. It could be that you are using ''track'' in > /etc/shorewall/interfaces and don''t have the internal interfaces listed > properly in the COPY column. This would cause the packet to 192.168.0.210 to > be send out of the wrong interface.That looks like a good guess, given these routing rules: 10512: from all fwmark 0x200 lookup aapt 10768: from all fwmark 0x300 lookup intn I''m guessing you have HIGH_ROUTE_MARKS=Yes and ''track'' on both providers? -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
You are completely correct I am using high-route-marks and I had eth0 in the providers rather than the vlans (adding vlan2,vlan3,etc). I''ve corrected this and it now works properly. Thanks very much for your time and thanks for your patience. One other thing that you may be interested in (and I can start a new post if you like) is that I get a "/usr/share/shorewall/compiler: line 263: exists_svpn2svpn:vlan2=Yes: command not found" on (re)start. You can see this in trace2.txt provided previously. It doesn''t seem to affect anything at this stage though. Thanks again, Denmat On 1/5/07, Tom Eastep <teastep@shorewall.net> wrote:> Tom Eastep wrote: > > Tom Eastep wrote: > >> denmat wrote: > >>> Hi, I''m very sorry about not posting the correct way, and thanks for > >>> your replies. > >>> > >>> I have attached the shorewall dump and the tshark trace below was > >>> captured on the external interface of the firewall. > >> Then I think that you need to look at the link-layer (MAC) source address of > >> the extra packet (the one addresses to 192.168.0.210). I suspect that it > >> will be 00:11:95:c7:13:03. > >> > > > > If it turns out to be some other MAC address (like whichever interface you > > call you are calling your ''external'' one[1]), then I need to see a dump with > > Shorewall started. It could be that you are using ''track'' in > > /etc/shorewall/interfaces and don''t have the internal interfaces listed > > properly in the COPY column. This would cause the packet to 192.168.0.210 to > > be send out of the wrong interface. > > That looks like a good guess, given these routing rules: > > 10512: from all fwmark 0x200 lookup aapt > 10768: from all fwmark 0x300 lookup intn > > I''m guessing you have HIGH_ROUTE_MARKS=Yes and ''track'' on both providers? > > -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 > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net''s Techsay panel and you''ll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > >------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
denmat wrote:> You are completely correct I am using high-route-marks and I had eth0 > in the providers rather than the vlans (adding vlan2,vlan3,etc). I''ve > corrected this and it now works properly. Thanks very much for your > time and thanks for your patience. > > One other thing that you may be interested in (and I can start a new > post if you like) is that I get a "/usr/share/shorewall/compiler: line > 263: exists_svpn2svpn:vlan2=Yes: command not > found" on (re)start. You can see this in trace2.txt provided previously. > > It doesn''t seem to affect anything at this stage though.I''d like to see a trace (you apparently didn''t attach it to your last post). -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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV