0

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
Robert Tupelo-Schneck
  • 121
  • 1
  • 12
  • 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](http://lifehacker.com/assets/resources/2006/10/ssh-mac-thumb.jpg)? – 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
  • Oops, sorry, I misread it. It looks like your ICMP error came from A to B. Which means you either have a firewall issue on A, or something in the network is messing with you. – Michael Hampton Jul 20 '12 at 18:27
  • I've added the firewall config from the server A. Is there anything obvious there that I'm missing? Or any way to tell that the problem comes from A or somewhere else on the network? – Robert Tupelo-Schneck Jul 20 '12 at 19:05

2 Answers2

1

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

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 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
0

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...

Robert Tupelo-Schneck
  • 121
  • 1
  • 12
  • 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