On 10/20/2015 4:47 AM, Norman Henderson wrote: > Summary: packets received on one vlan interface, are replied to on > another vlan. This is specific to the network for which an address is > defined on vlan1; another network for which an address is defined on > vlan1:1 is working correctly. > > Environment: Ubuntu 14.04.3 LTS, Linux Kernel 3.13.0-65, Shorewall > version 4.5.21.6 > > A firewall has 2 physical interfaces eth0 and eth1. eth1 does not have > its own address because it hosts 3 vlan interfaces vlan1, vlan2, > vlan3. eth0 is a direct Internet connection with several addresses in > the same subnet. vlan1 has a main address 10.0.69.1/24 and a second > address 10.0.70.1/24 which we use for printers, switch management etc. > vlan3 10.1.10.248/24 is routed to another site which has alternative > internet connectivity. vlan2 192.168.11.248/24 is also routed to > another site but is currently hardly used. NB: None of this has been > changed anytime recently. > > The firewall was running fine until Thursday night when I removed a > vtun client definition which had been connecting over vlan3 and > changed routing so that the network at the other end, is connected > directly over the routed network rather than via vtun. There is still > a vtun server which receives connections from a server elsewhere in > the world. Unfortunately I don't have detailed notes of all changes > but I don't think I did anything unusual - mainly vtun and shorewall > config changes. > > MAIN SYMPTOM: Another box 10.0.69.20 on the same VLAN vlan1 sends a > Ping to the firewall as 10.0.69.1. The ping reply is generated > however, it is sent back to 10.0.69.20 on vlan3 instead of vlan1 and, > of course, does not arrive. The same symptom occurs for ssh, and dns, > and presumably all traffic incoming to address 10.0.69.1 on tcp/udp > ports FROM ALL OTHER DEVICES on vlan1 with an IP of 10.0.69.x/24. > > Ping, ssh, and dns incoming to ANY permitted address including > 10.0.69.1 on the firewall work from other origins: devices on vlan1 > with addresses 10.0.70.x, devices anywhere in our networks with > arbitrary addresses (as long as the firewall has a valid return > route). For example, 10.1.10.200, 10.1.0.211 and 10.1.15.254 are able > to access the firewall equally well addressing it as 10.1.10.248, > 10.0.69.1, or 10.0.70.1. > > The firewall itself can ping out to anywhere, in fact all outbound > functions work. > >>From 10.0.69.20 I can arping 10.0.69.1 and I get a valid reply, the > MAC of vlan1 i.e. of eth1. As expected, 10.0.69.20 cannot arping > 10.0.70.1 (I guess that's due to arp_ignore=2). > > The firewall IS routing packets coming from arbitrary 10.0.69.x/24 > addresses (including 10.0.69.20) that are destined for the outside > world via vlan3 or eth0 and vice-versa. For example, 10.0.69.20 can > ping from 10.0.69.20 to 93.184.220.29 and gets a reply; both the ping > and reply are visible on the firewall on vlan1 and also on the > upstream interface vlan3. > > Devices on vlan1with an IP of 10.0.70.x/24 (if you prefer, vlan1:1 > addresses) can ping 10.0.70.1. In fact, devices on vlan1 with an IP of > 10.0.69.x can ping 10.0.70.1 (those packets are being being routed via > the firewall and are visible with tcpdump listening on vlan1). > > I have checked the switching topology. It consists of a gigabit > backbone, for which all of the ports that interconnect switches are > set for PVID 1, and are Tagged members of vlan 1, 2, and 3. Almost all > other ports in the network are set to Untagged on vlan 1 only, with > pvid 1. One port only on one switch is Untagged vlan2 (only), pvid2 > and a couple of ports on two switches are Untagged vlan3 (only), > pvid3. > > Shorewall zones: > Fwall firewall > CEM09 ipv4 > CEM01 ipv4 > CEM11 ipv4 > CEM50 ipv4 > NCI01 ipv4 > MAF01 ipv4 > UNI01 ipv4 > > Shorewall interfaces: > ?FORMAT 2 > #ZONE INTERFACE OPTIONS > CEM09 tun0 routeback,optional > CEM50 vlan3 routeback > UNI01 ppp0 optional > - vlan1 dhcp,arp_ignore=2 > NCI01 eth0 routefilter=1 > MAF01 vlan2 routeback #was wlan0 > > Shorewall hosts: > #ZONE HOSTS OPTIONS > CEM01 vlan1:10.0.69.0/24 routeback > CEM11 vlan1:10.0.70.0/24 routeback > > For test purposes I added three lines to the front of > shorewall/policy, here is the complete file: > Fwall all ACCEPT > CEM01 $FW ACCEPT > CEM11 $FW ACCEPT > > CEM01 CEM11 ACCEPT > CEM11 CEM01 ACCEPT > CEM11 CEM09 ACCEPT > CEM01 all REJECT info > CEM11 CEM50 REJECT info > CEM11 MAF01 REJECT info > CEM11 NCI01 REJECT > CEM11 UNI01 REJECT > CEM50 all REJECT info > CEM09 all REJECT info > NCI01 all REJECT > MAF01 all REJECT info > UNI01 all REJECT > > The rules are a mess but, given the wide-open policy in the first > three lines above, I don't believe there is a filtering problem. > > TCPDUMPs showing pings coming in on vlan1 and going out on vlan3: > > # tcpdump -i vlan1 host 10.0.69.20 and icmp > listening on vlan1, link-type EN10MB (Ethernet), capture size 65535 bytes > 08:37:24.521767 IP 10.0.69.20 > cem01fw-clean.ceml.net: ICMP echo > request, id 18086, seq 1, length 64 > 08:37:25.521082 IP 10.0.69.20 > cem01fw-clean.ceml.net: ICMP echo > request, id 18086, seq 2, length 64 > 08:37:26.529489 IP 10.0.69.20 > cem01fw-clean.ceml.net: ICMP echo > request, id 18086, seq 3, length 64 > ^C // note, there are no replies on vlan1 // > # tcpdump -i vlan3 host 10.0.69.20 and icmp > listening on vlan3, link-type EN10MB (Ethernet), capture size 65535 bytes > 08:37:38.667660 IP cem01fw-clean.ceml.net > 10.0.69.20: ICMP echo > reply, id 18098, seq 1, length 64 > 08:37:38.675847 IP cem01fw-clean.ceml.net > 10.0.69.20: ICMP echo > reply, id 18098, seq 1, length 64 > 08:37:39.667679 IP cem01fw-clean.ceml.net > 10.0.69.20: ICMP echo > reply, id 18098, seq 2, length 64 > ^C // note, ONLY replies appear on vlan3 // > > IPTABLES TRACE showing the same thing: > Oct 17 08:30:14 cem01fw kernel: [65995.522023] TRACE: > raw:PREROUTING:policy:14 IN=vlan1 OUT= > MAC=00:9c:02:aa:37:dd:78:e3:b5:fc:3c:22:08:00 SRC=10.0.69.20 > DST=10.0.69.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28169 DF PROTO=ICMP > TYPE=8 CODE=0 ID=17920 SEQ=9 > Oct 17 08:30:14 cem01fw kernel: [65995.522046] TRACE: > mangle:PREROUTING:policy:5 IN=vlan1 OUT= > MAC=00:9c:02:aa:37:dd:78:e3:b5:fc:3c:22:08:00 SRC=10.0.69.20 DST= > 10.0.69.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28169 DF PROTO=ICMP > TYPE=8 CODE=0 ID=17920 SEQ=9 > Oct 17 08:30:14 cem01fw kernel: [65995.522058] TRACE: > mangle:INPUT:policy:1 IN=vlan1 OUT= > MAC=00:9c:02:aa:37:dd:78:e3:b5:fc:3c:22:08:00 SRC=10.0.69.20 DST=10.0. > 69.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28169 DF PROTO=ICMP TYPE=8 > CODE=0 ID=17920 SEQ=9 > Oct 17 08:30:14 cem01fw kernel: [65995.522066] TRACE: > filter:INPUT:rule:2 IN=vlan1 OUT= > MAC=00:9c:02:aa:37:dd:78:e3:b5:fc:3c:22:08:00 SRC=10.0.69.20 > DST=10.0.69.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28169 DF PROTO=ICMP > TYPE=8 CODE=0 ID=17920 SEQ=9 > Oct 17 08:30:14 cem01fw kernel: [65995.522085] TRACE: > filter:vlan1_in:rule:4 IN=vlan1 OUT= > MAC=00:9c:02:aa:37:dd:78:e3:b5:fc:3c:22:08:00 SRC=10.0.69.20 > DST=10.0.69.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28169 DF PROTO=ICMP > TYPE=8 CODE=0 ID=17920 SEQ=9 > Oct 17 08:30:14 cem01fw kernel: [65995.522089] TRACE: > filter:CEM012Fwall:rule:1 IN=vlan1 OUT= > MAC=00:9c:02:aa:37:dd:78:e3:b5:fc:3c:22:08:00 SRC=10.0.69.20 > DST=10.0.69.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=28169 DF PROTO=ICMP > TYPE=8 CODE=0 ID=17920 SEQ=9 > Oct 17 08:30:14 cem01fw kernel: [65995.522106] TRACE: > raw:OUTPUT:policy:13 IN= OUT=vlan3 SRC=10.0.69.1 DST=10.0.69.20 LEN=84 > TOS=0x00 PREC=0x00 TTL=64 ID=50736 PROTO=ICMP TYPE=0 CODE=0 ID=1792 > 0 SEQ=9 > Oct 17 08:30:14 cem01fw kernel: [65995.522110] TRACE: > mangle:OUTPUT:policy:1 IN= OUT=vlan3 SRC=10.0.69.1 DST=10.0.69.20 > LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=50736 PROTO=ICMP TYPE=0 CODE=0 > ID=17920 SEQ=9 > Oct 17 08:30:14 cem01fw kernel: [65995.522113] TRACE: > filter:OUTPUT:policy:3 IN= OUT=vlan3 SRC=10.0.69.1 DST=10.0.69.20 > LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=50736 PROTO=ICMP TYPE=0 CODE=0 > ID=17920 SEQ=9 > Oct 17 08:30:14 cem01fw kernel: [65995.522115] TRACE: > mangle:POSTROUTING:policy:2 IN= OUT=vlan3 SRC=10.0.69.1 DST=10.0.69.20 > LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=50736 PROTO=ICMP TYPE=0 CODE=0 > ID=17920 SEQ=9 > > I'm so far out of my depth here, the water above me is black. Help!!! >
If you forward the output of 'shorewall dump', I can probably help you. But the output interface is determined by routing, and none of the configuration files you listed above alter the firewall's routing configuration. Please see http://www.shorewall.org/support.htm#Guidelines -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
