Hi Tom, the dump file was indeed attached, but anyway no worries - the problem is resolved! - Norman
On Thu, Oct 22, 2015 at 1:50 AM, Tom Eastep <[email protected]> wrote: > 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 >
------------------------------------------------------------------------------
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
