can't ping6: firewall?
Shadow Hawkins on Thursday, 21 February 2008 16:49:44
Hi all,
For some reason, I can't ping6:
aiccu seems to start OK:
# sixxs-aiccu start
Tunnel Information for T14342:
POP Id : nlams05
IPv6 Local : 2001:610:600:46e::2/64
IPv6 Remote : 2001:610:600:46e::1/64
Tunnel Type : 6in4-heartbeat
Adminstate : enabled
Userstate : enabled
But when i try to ping the surfnet gateway, it doesn't work:
$ ping6 2001:610:600:46e::1
PING6(56=40+8+8 bytes) 2001:610:600:46e::2 --> 2001:610:600:46e::1
ping6: sendmsg: Operation not permitted
ping6: wrote 2001:610:600:46e::1 16 chars, ret=-1
ping6: sendmsg: Operation not permitted
[...]
I thought it might be a firewall issue so I added these two rules (temporarily) to PF:
pass in on gif0 inet6 all flags S/SA keep state
pass out on gif0 inet6 all flags S/SA keep state
Still no go. What am I missing here?
I am running FreeBSD 7.0-PRERELEASE. ifconfig stuff:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
tunnel inet 172.19.3.3 --> 192.87.102.107
inet6 2001:610:600:46e::2 --> 2001:610:600:46e::1 prefixlen 128
inet6 fe80::202:55ff:feeb:6e65%gif0 prefixlen 64 scopeid 0x8
I have my Copperjet modem in ZIPB (half-bridge) mode so there is no NAT going on there.
Thanks.
can't ping6: firewall?
Shadow Hawkins on Thursday, 21 February 2008 19:48:55
By way of further investigation: running "sixxs-aiccu test" pinpoints at which point ping6 fails:
###### [4/8] Checking if we can ping IPv6 localhost (::1)
### This confirms if your IPv6 is working
### If ::1 doesn't reply then something is wrong with your IPv6 stack
PING6(56=40+8+8 bytes) ::1 --> ::1
16 bytes from ::1: Echo Request
16 bytes from ::1, icmp_seq=0 hlim=64 dst=::1%6 time=0.362 ms
16 bytes from ::1: Echo Request
16 bytes from ::1, icmp_seq=1 hlim=64 dst=::1%6 time=0.252 ms
16 bytes from ::1: Echo Request
16 bytes from ::1, icmp_seq=2 hlim=64 dst=::1%6 time=0.252 ms
--- ::1 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.252/0.289/0.362/0.052 ms
######
Did this work? [Y/n] y
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:610:600:46e::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING6(56=40+8+8 bytes) 2001:610:600:46e::2 --> 2001:610:600:46e::2
16 bytes from 2001:610:600:46e::2: Echo Request
16 bytes from 2001:610:600:46e::2, icmp_seq=0 hlim=64 dst=2001:610:600:46e::2%8 time=0.380 ms
16 bytes from 2001:610:600:46e::2: Echo Request
16 bytes from 2001:610:600:46e::2, icmp_seq=1 hlim=64 dst=2001:610:600:46e::2%8 time=0.268 ms
16 bytes from 2001:610:600:46e::2: Echo Request
16 bytes from 2001:610:600:46e::2, icmp_seq=2 hlim=64 dst=2001:610:600:46e::2%8 time=0.270 ms
--- 2001:610:600:46e::2 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.268/0.306/0.380/0.052 ms
######
Did this work? [Y/n] y
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:610:600:46e::1)
### This confirms the reachability of the other side of the tunnel
### If it doesn't reply then check your interface and routing tables
### Don't forget to check your firewall of course
### If the previous test was succesful then this could be both
### a firewalling and a routing/interface problem
PING6(56=40+8+8 bytes) 2001:610:600:46e::2 --> 2001:610:600:46e::1
ping6: sendmsg: Operation not permitted
ping6: wrote 2001:610:600:46e::1 16 chars, ret=-1
ping6: sendmsg: Operation not permitted
ping6: wrote 2001:610:600:46e::1 16 chars, ret=-1
ping6: sendmsg: Operation not permitted
ping6: wrote 2001:610:600:46e::1 16 chars, ret=-1
--- 2001:610:600:46e::1 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
Here is some routing info, in case it would be helpful:
$ netstat -r | grep gif
default gw-1135.ams-05.nl. UGS gif0
gw-1135.ams-05.nl. link#8 UHL gif0
fe80::%gif0 link#8 UC gif0
ff01:8:: link#8 UC gif0
ff02::%gif0 link#8 UC gif0
can't ping6: firewall?
Shadow Hawkins on Thursday, 21 February 2008 20:54:54
Yep, it looks like a firewall issue; from tcpdump:
999997 rule 8/0(match): block out on fxp0: 172.19.3.3 > 192.87.102.107: [|ip6]
I now see that the PF rules for gif0 were wrong; traffic for that interface still needs to pass through the external interface, in my case fxp0. So I try something like this:
[...]
block in log
block out log on $ext_if all
pass quick on $ext_if inet6 from any to any
[...]
But the ping6 packets are still being blocked. :?
can't ping6: firewall?
Shadow Hawkins on Thursday, 21 February 2008 22:37:15
Hi,
I once got it running with:
loop=lo0
gif=gif0
tunnelendv4=212..
[..]
#
# Allowed
#
pass quick on $loop
pass quick on $gif
pass in on $ext_if inet proto ipv6 all keep state
pass out on $ext_if inet proto ipv6 all keep state
pass in on $ext_if proto udp to $tunnel_end4 \
port 5072 modulate state \
(max-src-conn 50, max-src-conn-rate 10/10, overload <dip> flush)
,grep -i icmp6 /etc/protocols
ipv6-icmp 58 IPV6-ICMP icmp6 # ICMP for IPv6
I would add a similar proto rule for icmp6.
Greetz Stefan
can't ping6: firewall?
Jeroen Massar on Friday, 22 February 2008 00:28:51 ping6: sendmsg: Operation not permitted
Tells you that it is your firewall ruleset blocking the packet from being sent.
tunnel inet 172.19.3.3 --> 192.87.102.107
Tells you that there HAS to be NAT as 172.19.3.3 falls under 172.16.0.0/12 which is RFC1918.
As such you either have to configure your NAT box properly or simply use AYIYA.
can't ping6: firewall?
Shadow Hawkins on Friday, 22 February 2008 00:53:45 > tunnel inet 172.19.3.3 --> 192.87.102.107
Tells you that there HAS to be NAT as 172.19.3.3 falls under 172.16.0.0/12 which is RFC1918.
I am using something called ZIPB mode, also called half-bridge, whereby the Copperjet ADSL modem does no NAT; it simply forwards all incoming traffic to a given internal network interface, rather like a DMZ. 172.19.3.3 appears to the world as the external IP. See these links for more about ZIPB mode:
http://www.breedbandmodems.info/modules/content/index.php?id=107
http://www.routertech.org/viewtopic.php?p=15928
The advantages are a) that no NAT is done, and b) the Copperjet remains accessible via its web interface.
Trust me: The only NAT being done is on my FreeBSD box.
In any case, I have these rules now which should pass *anything*:
pass quick on gif0 inet6
pass quick on $ext_if inet6 from any to any
But still no go. :(
can't ping6: firewall?
Jeroen Massar on Friday, 22 February 2008 01:51:21 I am using something called ZIPB mode, [..marketing stuff..]
Trust me, it is a NAT.
You have a RFC1918 address configured on your box. As such it WILL be translated, if you like it or not and this definitely does break various protocols that don't have a supported ALG in the NAT box.
And most very likely one of the ALG's that is not implemented is proto-41.
What you want is a full bridge setup where the modem just has an IP address on the local interface, but doesn't touch the DSL data. It should only translate the DSL data from ATM (as that is how it enters the box) into Ethernet, and that is it.
can't ping6: firewall?
Shadow Hawkins on Friday, 22 February 2008 02:02:20
Thanks to the help of someone on the freebsd-questions list, I finally got it working:
pass quick on fxp0 proto ipv6 all keep state
pass quick on gif0 inet6 all flags S/SA keep state
can't ping6: firewall?
Shadow Hawkins on Saturday, 23 February 2008 21:27:25
Jeroen: I stand corrected. ZIPB wasn't configured properly. I fixed it:
$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
tunnel inet 78.27.4.200 --> 192.87.102.107
inet6 fe80::202:55ff:feeb:6e65%gif0 prefixlen 64 scopeid 0x8
inet6 2001:610:600:46e::2 --> 2001:610:600:46e::1 prefixlen 128
I have also written a little script to update the interface when my IP changes.
What you want is a full bridge setup
From what I've been able to determine, full bridge isn't (generally?) feasible with PPPoA. There aren't any commonly available PPPoA stacks, hence one is dependent on the ADSL modem to manage it. The Copperjet for one doesn't offer a full bridge with PPPoA, so for better or worse I'll be using ZIPB for the time being.
In any case, the IPv6 tunnel is working very well. My LAN clients see it is as well, and I can see the dancing turtle. 8-)
I am really impressed with this site and all the work you guys have put into this.
Thanks,
Colin
Posting is only allowed when you are logged in. |