On 03/30/2012 07:56 PM, AD wrote: As discussed on IRC I noticed my configuration stopped working for Shorewall 4.4.22.1, and in fact the change appears to be somewhere in this followin patch because it used to work fine in 4.4.21.1: http://www1.shorewall.net/pub/shorewall/4.4/shorewall-4.4.22/patch-4.4.22 .
I have attached a dump and my interfaces file. The problem happens on
the host's interface br10 which is bridged to a veth interface on the
OpenVZ guest. This interface has the dhcp option set in the interfaces
file, like it should. Clearing the host's shorewall allows the DHCP
traffic to reach the guest. Nothing useful gets logged.
Please excuse the HTML response, but in plain text mode my mailer
insists on folding long lines, making it difficult to quote from a dump.
I'm not seeing any problem with the Shorewall-generated ruleset:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
867 232K dynamic all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate INVALID,NEW
0 0 br103_in all -- br103 * 0.0.0.0/0 0.0.0.0/0
5092 427K br112_in all -- br112 * 0.0.0.0/0 0.0.0.0/0
615 204K br301_in all -- br301 * 0.0.0.0/0 0.0.0.0/0
0 0 br303_in all -- br303 * 0.0.0.0/0 0.0.0.0/0
211 22850 br8_in all -- br8 * 0.0.0.0/0 0.0.0.0/0
1025 60308 br9_in all -- br9 * 0.0.0.0/0 0.0.0.0/0
584 150K br1_in all -- br1 * 0.0.0.0/0 0.0.0.0/0
0 0 br3_in all -- br3 * 0.0.0.0/0 0.0.0.0/0
9 506 tor2fw all -- br104 * 0.0.0.0/0 0.0.0.0/0
policy match dir in pol none
0 0 venet0_in all -- venet0 * 0.0.0.0/0 0.0.0.0/0
0 0 br111_in all -- br111 * 0.0.0.0/0 0.0.0.0/0
0 0 br10_in all -- br10 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
14 3248 Reject all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:'
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
[goto]
So traffic entering the firewall on br10 is sent to the br10_in chain:
Chain br10_in (1 references)
pkts bytes target prot opt in out source destination
0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate INVALID,NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpts:67:68
0 0 wifi2fw all -- * * 10.3.10.0/24 0.0.0.0/0
policy match dir in pol none
The second rule accepts DHCP traffic on input. I believe that it is
significant to note that _no_ packets were routed through br10_in during
the period covered by the dump (over an hour). There were 14 Broadcast
packets from somewhere that didn't match any of the preceding rules
though (note the 14 packets sent to Reject):
Chain Reject (76 references)
pkts bytes target prot opt in out source destination
14 3248 all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:113 /* Auth */
14 3248 Broadcast all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
icmp type 3 code 4 /* Needed ICMP types */
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
icmp type 11 /* Needed ICMP types */
0 0 Invalid all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0
multiport dports 135,445 /* SMB */
0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpts:137:139 /* SMB */
0 0 reject udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spt:137 dpts:1024:65535 /* SMB */
0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0
multiport dports 135,139,445 /* SMB */
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:1900 /* UPnP */
0 0 NotSyn tcp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spt:53 /* Late DNS Replies */
There are DHCP packets coming from some interface (possibly from br1).
From the connection tracking table:
udp 17 24 src=0.0.0.0 dst=255.255.255.255 sport=68 dport=67 packets=2813
bytes=932311 [UNREPLIED] src=255.255.255.255 dst=0.0.0.0 sport=67 dport=68
packets=0 bytes=0 mark=0 secmark=0 use=1
For output:
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 br103_out all -- * br103 0.0.0.0/0 0.0.0.0/0
5083 427K br112_out all -- * br112 0.0.0.0/0 0.0.0.0/0
0 0 fw2ext all -- * br301 0.0.0.0/0 0.0.0.0/0
policy match dir out pol none
0 0 br303_out all -- * br303 0.0.0.0/0 0.0.0.0/0
125 10500 fw2ari all -- * br8 0.0.0.0/0 0.0.0.0/0
policy match dir out pol none
1265 450K fw2ari all -- * br9 0.0.0.0/0 0.0.0.0/0
policy match dir out pol none
752 40448 fw2ari all -- * br1 0.0.0.0/0 0.0.0.0/0
policy match dir out pol none
0 0 fw2ari all -- * br3 0.0.0.0/0 0.0.0.0/0
policy match dir out pol none
0 0 fw2tor all -- * br104 0.0.0.0/0 0.0.0.0/0
policy match dir out pol none
0 0 fw2ovpn all -- * venet0 0.0.0.0/0 0.0.0.0/0
policy match dir out pol none
0 0 br111_out all -- * br111 0.0.0.0/0 0.0.0.0/0
0 0 br10_out all -- * br10 0.0.0.0/0 0.0.0.0/0
So traffic destined for br10 is sent through br10_out
Chain br10_out (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpts:67:68
0 0 fw2wifi all -- * * 0.0.0.0/0
10.3.10.0/24 policy match dir out pol none
0 0 fw2wifi all -- * * 0.0.0.0/0
255.255.255.255 policy match dir out pol none
0 0 fw2wifi all -- * * 0.0.0.0/0 224.0.0.0/4
policy match dir out pol none
The first rule accepts DHCP traffic.
So let's turn to the IP configuration:
IP Configuration
2: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
inet 127.0.0.1/8 scope host lo
6: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.99.26/29 brd 192.168.99.31 scope global eth2
37: br111: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 10.0.111.1/24 brd 10.0.111.255 scope global br111
inet 192.168.103.2/24 brd 192.168.103.255 scope global br111:0
261: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 10.16.21.254/24 brd 10.16.21.255 scope global br1
inet 192.168.20.56/28 brd 192.168.20.63 scope global br1:0
263: br301: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 10.99.0.6/24 brd 10.99.0.255 scope global br301
inet 192.168.1.6/24 brd 192.168.1.255 scope global br301:0
267: br3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 10.16.22.1/24 brd 10.16.22.255 scope global br3
269: br7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 10.16.20.56/27 brd 10.16.20.63 scope global br7:0
271: br8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 10.16.16.254/24 brd 10.16.16.255 scope global br8
273: br9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 10.3.1.16/24 brd 10.3.1.255 scope global br9
inet 10.16.20.1/27 brd 10.16.20.31 scope global br9:0
277: br101: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 192.168.99.4/29 brd 192.168.99.7 scope global br101:0
279: br103: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 192.168.99.21/29 brd 192.168.99.23 scope global br103:0
281: br104: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 192.168.99.26/29 brd 192.168.99.31 scope global br104
283: br112: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
inet 145.11.41.195/29 brd 145.11.41.199 scope global br112
br10 doesn't have an IP address. So if that worked with Shorewall-4.4.21, it is
a mystery to me as to how it did it. If you forward a dump with 4.4.21, I'll
compare the two to see if I missed something in the above analysis.
-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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
