IP Masq doesn't work with a bridge and IPv6 blocked

Bug #38288 reported by Roshan Shariff
8
Affects Status Importance Assigned to Milestone
linux-source-2.6.15 (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Description:

Masquerading does not work for connections from a bridge if the default policy for IPv6 forwarding in ip6tables is 'drop'. The IPv6 policy should not have any effect on IPv4 traffic.

I encountered this bug while setting up shorewall 3.0.4 on dapper with kernel 2.6.15 amd64 smp. I have determined that the problem is not specific to shorewall and also occurs on breezy's 2.6.12 amd64 kernel (non-smp).

The discussion that led to the discovery of this bug can be found on the shorewall-users list at [1].

Network configuration:

bridge (lan0) with one port (eth0)
internet access through PPPoE link ppp0

Steps to Reproduce:

1. Create a bridge with "brctl addbr lan0"

2. Add eth0 to the bridge with "brctl addif lan0 eth0" and "ifconfig eth0 0.0.0.0 up"

3. Configure lan0 with a static IP address

4. Enable IP Forwarding with "echo 1 > /proc/sys/net/ipv4/ip_forward"

2. Enable masquerading wih "iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j MASQUERADE"

2a. At this point masquerading works fine

3. Disable forwarding of IPv6 with "ip6tables -P FORWARD DROP"

Expected Results:

Masquerading should work fine and systems on lan0 should be able to access the internet through ppp0

Actual results:

Systems on the lan cannot connect to the Internet. However everything works fine if the ip6tables drop policy is not added.

Setting the policy of the INPUT and OUTPUT IPv6 chains to DROP doesn't affect access to/from the firewall host. Only forwarding is affected.

This should not happen since blocking IPv6 traffic should not have any effect on IPv4 traffic. Apart from this, the problem only occurs when the internal interface is a bridge, not when it is a normal interface.

Tom Eastep (the author of Shorewall) says that it is a security breach to allow IPv6 traffic through the firewall, since an attacker could just send IPv6 traffic to bypass the firewall.

I will attach the output of tcpdump -nvvi ppp0 port 80 with the IPv6 policy set to 'drop' and with it set to 'accept', while trying to browse www.google.com

[1] http://sourceforge.net/mailarchive/forum.php?thread_id=10103319&forum_id=2270

Revision history for this message
Roshan Shariff (roshan.shariff) wrote : Tcpdump output (working)

This is the output of tcpdump -nvvi ppp0 port 80 with the IPv6 forwarding policy set to 'ACCEPT'. I'm browsing www.google.com from a LAN computer and it works fine.

Revision history for this message
Roshan Shariff (roshan.shariff) wrote : Tcpdump output (not working)

This is the output of tcpdump -nvvi ppp0 port 80 with the IPv6 forwarding policy set to 'DROP'. Browsing www.google.com from a LAN computer doesn't work. The browser just says Connecting... and doesn't go further.

Revision history for this message
Gareth Fitzworthington (mapping-gp-deactivatedaccount) wrote :

This bug has had no activity for a considerable period. This is a check to see if there is still interest in investigating this bug report.

Changed in linux-source-2.6.15:
status: New → Incomplete
Revision history for this message
Gareth Fitzworthington (mapping-gp-deactivatedaccount) wrote :

Closing.

Changed in linux-source-2.6.15:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.