• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Can't route LAN through SuSEfirewall2

Started by w1nr, January 05, 2010, 04:09:30 AM

Previous topic - Next topic

w1nr

I am running an openSUSE 11.2 server that is also my ipv4 NAT router for my LAN. After setting up an ipv6 tunnel, I can get to and from the server via ipv6 without any problem. I set up the LAN interface to use my routed /64 and set up a workstation on the LAN for the same ipv6 subnet. The workstation can access the server via ipv6 and can even ping the server's tunnel endpoint address. However, when SuSEfirewall2 is enabled on the server, nothing gets routed over the tunnel. If I shut down the firewall, the workstation can access ipv6 hosts through the tunnel just fine so the routing seems correct. I have tried many different parameters in the config file to no avail. Running without the firewall enabled is NOT an option as then my LAN ipv4 access will stop.

On the LAN client I get:


# ping6 ftp.ipv6.heanet.ie
PING ftp.ipv6.heanet.ie(ftp.heanet.ie) 56 data bytes
From 2001:470:1f07:a4f::1 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:470:1f07:a4f::1 icmp_seq=2 Destination unreachable: Address unreachable
From 2001:470:1f07:a4f::1 icmp_seq=3 Destination unreachable: Address unreachable
From 2001:470:1f07:a4f::1 icmp_seq=4 Destination unreachable: Address unreachable
From 2001:470:1f07:a4f::1 icmp_seq=5 Destination unreachable: Address unreachable
From 2001:470:1f07:a4f::1 icmp_seq=6 Destination unreachable: Address unreachable



and on the server in /var/log/firewall I get:



Jan  5 07:03:48 curly kernel: [66436.462641] SFW2-FWDint-DROP-DEFLT IN=eth0 OUT=sit1 SRC=2001:0470:1f07:0a4f:0000:0000:0000:0044 DST=2001:0470:0000:0063:0000:0000:0000:0002 LEN=80 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=TCP SPT=35998 DPT=80 WINDOW=5760 RES=0x00 SYN URGP=0 OPT (020405A00402080A0007C9810000000001030306)
Jan  5 07:05:25 curly kernel: [66533.565799] SFW2-FWDint-DROP-DEFLT IN=eth0 OUT=sit1 SRC=2001:0470:1f07:0a4f:0000:0000:0000:0044 DST=2001:0770:0018:aa40:0000:0000:c101:c140 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=55825 SEQ=1
Jan  5 07:05:26 curly kernel: [66534.568206] SFW2-FWDint-DROP-DEFLT IN=eth0 OUT=sit1 SRC=2001:0470:1f07:0a4f:0000:0000:0000:0044 DST=2001:0770:0018:aa40:0000:0000:c101:c140 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=55825 SEQ=2
Jan  5 07:05:27 curly kernel: [66535.568225] SFW2-FWDint-DROP-DEFLT IN=eth0 OUT=sit1 SRC=2001:0470:1f07:0a4f:0000:0000:0000:0044 DST=2001:0770:0018:aa40:0000:0000:c101:c140 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=55825 SEQ=3


I assume some sort of custom firewall rule needs to be set up or there is some config parameter I missed, but I have no idea what the proper syntax would be. Any help appreciated.  ;)

Thanks,
Mike

cholzhauer

Well, what is your current firewall config?

w1nr

ifconfig is attached as ifconfig.txt
/etc/sysconfig/SuSEfirewall2 is SuSEfirewall2.txt
ip6tables -L is ip6tables.txt

Thanks, Mike



jimb

#3
Could you do an "ip6tables -v -n --list" so the interfaces are also listed?

From glancing at the FORWARD chain rules (and called chains), one thing I don't see is a rule which simply allows new outbound traffic.  All of the outbound rules (with your routed /64 as source) have the state condition of "related or established" set, which won't match a newly initiated traffic packets.

There should be a rule in your FORWARD chain (or any chains it calls) that reads something like:

target     prot opt source               destination        
ACCEPT     all      2001:470:1f07:a4f::/64  anywhere


or

target     prot opt source               destination        
ACCEPT     all      2001:470:1f07:a4f::/64  anywhere    state NEW,RELATED,ESTABLISHED

(keyword here NEW)

For instance, on my setup, I have a line like:
pkts bytes target     prot opt in     out     source               destination        
271 25053 ACCEPT     all      eth0    any     2001:db8:357c::/48  anywhere            


This allows all outbound traffic originating from my internal IPv6 LANs, coming in on the internal FW interface.  I don't see such a rule anywhere in your FORWARD chain, so ip6tables is dropping all new outbound traffic, as indicated by log entries such as:

Jan  5 07:05:25 curly kernel: [66533.565799] SFW2-FWDint-DROP-DEFLT IN=eth0 OUT=sit1 SRC=2001:0470:1f07:0a4f:0000:0000:0000:0044 DST=2001:0770:0018:aa40:0000:0000:c101:c140 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=55825 SEQ=1

(note that this is dropping outbound traffic to the ftp server you are pinging)

BTW, do you also have a Moe, Larry and Shemp?  :P

snarked

I also note that your SIT interfaces don't have IPv4 addresses.  Therefore, exactly what IPv4 address(es) are they supposed to use as the source for encapsulated packets.

Ifconfig lists interfaces in alphabetical order.  However, you probably brought "eth0" up before "ax0", so in the internal table, the first IPv4 address associated with any interface found is an RFC 1918 address (192.168.73.1) which is also a problem as this may be your kernel's default selection.

You're obviously doing something unconventional in order for sit0 to have inet6 ::127.0.0.2/96 on its interface.

I also find it strange that you're using SuSEfirewall2 instead of iptables, especially when using ip6tables on the IPv6 side.  I also agree that your attached ip6tables output is not useful without the "-v" option - as some entries may be tied to specific interfaces.

General firewall design:
Although you do break up the primary chains into sub-chains, you might want to consider restricting certain things to address ranges at the primary level.  The way I designed my firewall is to have the primary chains break out by virtual host (or host-subnet) and a few special functions (icmp/icmpv6), then conclude them with a catchall "-m state ESTABLISHED,RELATED" that catches things like "passive ftp."  Lastly, I note that your SSH port is open to the world (although it appears you're on a non-standard port value).  Once you have the ruleset fully working, consider hiding SSH behind a "port-knocking" setup.  This normally involves the "recent" module used with a time limit.  Don't use recent's -rttl function - as I found that my OS and my SSH client had different opinions as to the initial TTL/HL value to use.  A "double-knock" I have found to be unnecessary.

For the IPv6 firewall, don't forget that some ICMP6 packets for routing and neighbors use source addresses in the FE80::/10 and FF00::/8 ranges, and sometimes ::/128.

Lastly, don't forget to turn on packet forwarding in your /proc filesystem.

w1nr

#5
OK, the blind man can finally see. After realizing I could ping and portscan my internal address I realized that I reversed the forwarding rule in the config file. It should read

FW_FORWARD="2001:470:xxxx:xxxx::/64,2000::/3"

I had them reversed allowing traffic in from the OUTSIDE rather than LAN to internet6. Hopefully someone who hits the same issue will have some benefit from this post.

To answer a couple of questions, SuSEfirewall2 is a front end for iptables. The syntax is better than raw iptables but there are probably better choices. I should investigate shorewall.

BTW: I do have moe, larry, shemp and even an omay too!  :P

Mike

jimb

Glad to see you got it working.  As I'm unfamiliar with the particular ip[6]tables script you're using, I figure I'd just show you what was wrong in the actual ip6tables commands rather then trying to figure out what the script is doing with those conf file variables.   :P

Personally, I avoid those things.  I just do my own ip[6]tables setup.  I find the interface to be fairly simple, but then, I've have lots of people tell me that it was complicated and they couldn't get it to work, etc.  I don't know.  Maybe my years of working with various firewalls (Checkpoint, PIXen, Netscreen, etc) gives me some insight?  Netfilter/iptables is a bit "different" though, because of the concept of chains and tables, etc.

Anyway, I have heard "good" things about shorewall, but I've never tried it.