Help please! 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.
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 has several addresses in the same subnet and vlan1 has a second address in a different subnet which we use for printers, switch management etc. Eth0 is a direct Internet connection; vlan3 is routed to another site which has internet connectivity. vlan2 is routed to another site also and 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 and changed routing so that the network at the other end, is connected directly over our own routed network rather than via the 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 to 10.0.69.1. The ping reply is generated however, it is sent to 10.0.69.20 on vlan3 instead of vlan1 and, of course, does not arrive. The same symptom occurs for ssh, and dns incoming to address 10.0.69.1 FROM OTHER DEVICES on vlan1 with an IP of 10.0.69.x. 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 in our routed network 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 (due to arp_ignore=2). The firewall IS routing packets coming from arbitrary 10.0.69.x 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 vlan1 with an IP of 10.0.70.x 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 the first three lines to shorewall/policy: 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 # 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 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
shorewall_dump.gz
Description: GNU Zip compressed data
interfaces
Description: Binary data
------------------------------------------------------------------------------
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
