Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm testing on IPv6. A is a server in a Cogent colo with native IPv6, call it 2001:db8:1111::1. B is a Mac mini behind an Airport Extreme router behind ISP Comcast; the router is set up to use anycast 6to4, and B is let's say 2002:c000:202::2.

On B, ssh 2001:db8:1111::1 works just fine.

On A, ssh 2002:c000:202::2 times out. (Same for any other TCP connection.) Running tcpdump -nnvvvSs0 on B, I can see that the SYN packet from A reaches B just fine, but the SYN-ACK packet back from B to A is told "destination unreachable, unreachable prohibited":

12:16:42.266203 IP6 (hlim 51, next-header TCP (6) payload length: 40) 2001:db8:1111::1.43263 > 2002:c000:201::2.22: Flags [S], cksum 0x6c79 (correct), seq 102729844, win 5760, options [mss 1440,sackOK,TS val 749393277 ecr 0,nop,wscale 7], length 0
12:16:42.266330 IP6 (flowlabel 0xb4ac1, hlim 64, next-header TCP (6) payload length: 44) 2002:c000:202::2.22 > 2001:db8:1111::1.43263: Flags [S.], cksum 0xa0e9 (correct), seq 122191294, ack 102729845, win 65535, options [mss 1440,nop,wscale 3,nop,nop,TS val 1053035827 ecr 749393277,sackOK,eol], length 0
12:16:42.403695 IP6 (hlim 51, next-header ICMPv6 (58) payload length: 92) 2001:db8:1111::1 > 2002:c000:202::2: [icmp6 sum ok] ICMP6, destination unreachable, length 92,  unreachable prohibited 2001:db8:1111::1

It definitely seems striking that B can send a SYN to A and set up a connection, but B's SYN-ACK is rejected. Where should I look next to see why this is happening?

Edit: Here's the /etc/sysconfig/ip6tables from the server A:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmpv6 -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d ff02::fb -j ACCEPT
#-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
#-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
#-A RH-Firewall-1-INPUT -p udp -m udp --dport 32768:61000 -j ACCEPT
#-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 32768:61000 ! --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m udp -p udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A RH-Firewall-1-INPUT -j DROP

COMMIT
share|improve this question
1  
Next check your Mac's firewall settings. And for the love of all that is holy, use native dual stack if Comcast has provided it in your area yet. –  Michael Hampton Jul 20 '12 at 17:23
    
Agreed on native dual stack, but not available. No firewall on the Mac ("B"). B's router is letting through port 22 on IPv6, as is clear from the fact that A's SYN reaches B. –  Robert Tupelo-Schneck Jul 20 '12 at 17:43
1  
If you really took the packet capture from B, then that's almost certainly a firewall issue, since B would be originating the ICMPv6 reply. Are you absolutely certain you enabled access to ssh in System Preferences? –  Michael Hampton Jul 20 '12 at 17:52
    
The packet capture was on B. But why do you say that B is originating the ICMPv6 reply? I would have assumed that the ICMPv6 reply came from A, in response to B's SYN-ACK. ssh into B works just fine from the local network over IPv6, and from remote machines via IPv4 (with NAT). –  Robert Tupelo-Schneck Jul 20 '12 at 18:16
    
Other TCP connections from A to B meet a similar fate. If there's nothing on B (the Mac) listening on a given port, B tries to send a RST packet. But B receives the ICMPv6 reply, and A times out. –  Robert Tupelo-Schneck Jul 20 '12 at 18:21

2 Answers 2

It sounds like you are missing an ip6tables rule like the following:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
share|improve this answer
    
It seems clear we want this, but it didn't solve the problem. In any case it seems clear that the firewall is where the problem is. Still investigating. –  Robert Tupelo-Schneck Jul 23 '12 at 14:54

Changing the firewall on A fixed it. We added

-A RH-Firewall-1-INPUT -s 2002:c000:202::2 -j ACCEPT

before

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp6-adm-prohibited

It's still a bit mysterious to me why this is needed, when B -> A already worked...

share|improve this answer
    
I believe this might be a less secure approach to the ESTABLISHED,RELATED rule. B->A rules should be matching the other rules. A->B responses were not matching any rules. –  BillThor Jul 20 '12 at 23:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.