|
Are outgoing port 25 TCP connections blocked?
![[ca]](/s/countries/ca.gif) Shadow Hawkins on Saturday, 20 December 2014 09:10:19
The tunnel I created 12 days ago generally works very well. Thanks for this great service.
There is one issue: I'm running a mail server and want to use it via IPv6 through the tunnel. Although everything else seems to work fine, the outgoing connections to port 25 time out. I've tried four different destination mx servers with aaaa records, including the one for gmail.com and see the same problem with all of them.
Is this supposed to work, or is port 25 intentionally blocked? The POP is uslax03.
I've looked at the ip6tables rules and see that port 25 is explicitly opened together with a few others, so I don't think it is blocked on my side.
Thanks,
Joachim
Are outgoing port 25 TCP connections blocked?
Nothing is blocked by the SixXS PoPs, see the FAQ for more details.
I've looked at the ip6tables rules and see that port 25 is explicitly opened together with a few others, so I don't think it is blocked on my side.
If you want help debugging, check your DROP/REJECT logs and of course check tcpdump.
Are outgoing port 25 TCP connections blocked?
Shadow Hawkins on Monday, 22 December 2014 01:15:41
Thanks for confirming your no-filtering polcy. I had seen this in the FAQ section, but wanted to double-check because it looked as if packets were beeing blocked, and it still looks that way. Of course, it is difficult to be sure where the dropping occurs.
The tcpdump output displays several outgoing TCP SYN packets, but nothing coming back:
root@penguin:/tmp# tcpdump -r dump.pcap 'port 25'
reading from file dump.pcap, link-type RAW (Raw IP)
16:58:31.357561 IP6 penguin.kraut.ca.44616 > pc-in-x1b.1e100.net.smtp: Flags [S], seq 4162479397, win 24400, options [mss 1220,sackOK,TS val 13491768 ecr 0,nop,wscale 6], length 0
16:58:32.355101 IP6 penguin.kraut.ca.44616 > pc-in-x1b.1e100.net.smtp: Flags [S], seq 4162479397, win 24400, options [mss 1220,sackOK,TS val 13492018 ecr 0,nop,wscale 6], length 0
16:58:34.359098 IP6 penguin.kraut.ca.44616 > pc-in-x1b.1e100.net.smtp: Flags [S], seq 4162479397, win 24400, options [mss 1220,sackOK,TS val 13492519 ecr 0,nop,wscale 6], length 0
16:58:38.363107 IP6 penguin.kraut.ca.44616 > pc-in-x1b.1e100.net.smtp: Flags [S], seq 4162479397, win 24400, options [mss 1220,sackOK,TS val 13493520 ecr 0,nop,wscale 6], length 0
Nothing shows up in the iptables/ip6tables log. The configuration is created by the Arno Iptables Firewall script, and I have posted a question on their mailing list too. The response was that this should be working.
This leaves be puzzled about where exactly the dropping happens. Is it already on my system (probbaly)? Is it related to the tunnel (apparently not, from what you wrote), or is it on the receiving end? I don't have another IPv6 site on the Internet to play with, so I can't be sure what the other side does. The test above is using one of the gmail mx hosts. I've also tried three other sites with claimed IPv6 support, and all failed in the same way.
Any suggestions what to try next to isolate the problem?
Thanks,
Joachim
Jeroen Massar wrote:
Nothing is blocked by the SixXS PoPs, see the FAQ for more details.
I've looked at the ip6tables rules and see that port 25 is explicitly opened together with a few others, so I don't think it is blocked on my side.
If you want help debugging, check your DROP/REJECT logs and of course check tcpdump.
Are outgoing port 25 TCP connections blocked?
The tcpdump output displays several outgoing TCP SYN packets, but nothing coming back: root@penguin:/tmp# tcpdump -r dump.pcap 'port 25'
You might want to check with the -n option (as hostnames tend to be useless), you also might want to ensure that the remote side is not filtering (you likely do not control that google IP).
And there might be ICMP involved there.
Oh and don't forget that your routing can cause packets to go to /dev/null too and thus not cause any response.
Nothing shows up in the iptables/ip6tables log.
Unless there are LOG targets, they won't. You need to check counters.
The configuration is created by the Arno Iptables Firewall script, and I have posted a question on their mailing list too. The response was that this should be working.
Without the actual generated rules, who can say.
Are outgoing port 25 TCP connections blocked?
Shadow Hawkins on Tuesday, 06 January 2015 09:52:57
Got diverted by some other things, including conversion of my DNS zones to DNSSEC. In the meantime I have acquired another system with IPv6 connectivity. Since I have control over that system I can run listening endpoints, and have confirmed that the problem is not caused by the remote system. There is no problem connecting to that system at port 26, but for port 25 the SYN packets receive no reply.
The tcpdump output with the -n option is not revealing anything new:
# tcpdump -n -r dump port smtp
reading from file dump, link-type LINUX_SLL (Linux cooked)
00:51:59.208629 IP6 2001:4830:1a00:8012::1.36519 > 2a02:128:4:5::fc.25: Flags [S], seq 555971897, win 24400, options [mss 1220,sackOK,TS val 344593731 ecr 0,nop,wscale 6], length 0
00:52:00.207110 IP6 2001:4830:1a00:8012::1.36519 > 2a02:128:4:5::fc.25: Flags [S], seq 555971897, win 24400, options [mss 1220,sackOK,TS val 344593981 ecr 0,nop,wscale 6], length 0
00:52:02.211097 IP6 2001:4830:1a00:8012::1.36519 > 2a02:128:4:5::fc.25: Flags [S], seq 555971897, win 24400, options [mss 1220,sackOK,TS val 344594482 ecr 0,nop,wscale 6], length 0
00:52:06.219127 IP6 2001:4830:1a00:8012::1.36519 > 2a02:128:4:5::fc.25: Flags [S], seq 555971897, win 24400, options [mss 1220,sackOK,TS val 344595484 ecr 0,nop,wscale 6], length 0
I've saved the ip6tables contents, and the entries that reference port 25 are here:
-A EXT_INPUT_CHAIN -p tcp -m tcp --dport 25 -j ACCEPT
-A LAN_INET_FORWARD_CHAIN -s 2001:4830:1a00:12::2/128 -p tcp -m tcp --dport 25 -j ACCEPT
-A LAN_INET_FORWARD_CHAIN -s 2001:4830:1a00:8012::1/128 -p tcp -m tcp --dport 25 -j ACCEPT
-A LAN_INET_FORWARD_CHAIN -p tcp -m tcp --dport 25 -m limit --limit 1/sec --limit-burst 1 -j LOG --log-prefix "AIF:LAN->INET denied: " --log-level 6
-A LAN_INET_FORWARD_CHAIN -p tcp -m tcp --dport 25 -j DROP
The accept lines should apply to the source address used, the drop lines are for the internal network. I could post the complete ip6tables, but this is probably too big for the blog. The logging implied here for internal nodes attempting to connect to port 25 is not seen.
There are equivalent lines in the IPv4 iptables, but the IPv4 connection to port 25 works fine (not going through the tunnel, of course), and IPv6 to port 26 works too (through the tunnel).
Thanks,
Joachim
Are outgoing port 25 TCP connections blocked?
Try first without any firewall rules, then you know if those are the problem.
Are outgoing port 25 TCP connections blocked?
Shadow Hawkins on Wednesday, 07 January 2015 08:04:35
Jeroen Massar wrote:
Try first without any firewall rules, then you know if those are the problem.
Thanks for the suggestion. After disabling the firewall script and rebooting, the iptables-save and ip6tables-save commands produce no output, hence there are no rules or filters, and no NAT, so no IPv4 connectivity from internal nodes.
The problem with outgoing port 25 TCP connections is unchanged. It still times out, no response to the SYN packets. Port 26 still works. The problem is not caused by iptables/ip6tables.
The "hosts.allow" and "hosts.deny" files are empty, except for comments, Now what?
I suppose it could be a filter in the cable modem, but this seems very unlikely. It would have to look inside the encapsulated 6in4 packets. There is no good reason why the ISP would do this, and this is a Docsis v2 modem, which has no IPv6 support.
Thanks,
Joachim
Are outgoing port 25 TCP connections blocked?
Thanks for the suggestion. After disabling the firewall script and rebooting, the iptables-save and ip6tables-save commands produce no output, hence there are no rules or filters, and no NAT, so no IPv4 connectivity from internal nodes.
Did you check the output of 'ip6tables -v --list -n --line-numbers' and the same for 'iptables'?
Looking at the actually running configuration is a lot more important to what some utilities make out of it.
The "hosts.allow" and "hosts.deny" files are empty, except for comments, Now what?
These files are not typically used for outgoing connections and even for incoming connections it really depends on the server utility if it uses it, which is less and less.
I suppose it could be a filter in the cable modem, but this seems very unlikely. It would have to look inside the encapsulated 6in4 packets. There is no good reason why the ISP would do this, and this is a Docsis v2 modem, which has no IPv6 support.
It is really rare for ISPs to inspect tunnels. (not excluding it, but it rarely happens).
Another thing for you to double check is your routing. Are you sending the packet out the correct interface? 'ip -6 ro get <address>' and 'tracepath6 <address>' can reveal a lot here.
Are outgoing port 25 TCP connections blocked?
Just in case, inbound to port 25 works:
$ telnet 2001:4830:1a00:8012::1 25
Trying 2001:4830:1a00:8012::1...
Connected to 2001:4830:1a00:8012::1.
Escape character is '^]'.
220 penguin.kraut.ca ESMTP Exim 4.84 Wed, 07 Jan 2015 00:22:26 -0800
^]
Outbound (-b == source address selection):
$ telnet -b 2001:4830:1aff:8012::1 2a02:128:4:5::fc 25
Trying 2a02:128:4:5::fc...
telnet: Unable to connect to remote host: Connection refused
tcpdump:
00:28:20.976597 IP6 2001:4830:1aff:8012::1.40096 > 2a02:128:4:5::fc.25: Flags [S], seq 2332048429, win 14400, options [mss 1440,sackOK,TS val 1637119144 ecr 0,nop,wscale 5], length 0
00:28:21.122178 IP6 2a02:128:4:5::fc.25 > 2001:4830:1aff:8012::1.40096: Flags [R.], seq 0, ack 2332048430, win 0, length 0
The gmail example:
dig +short gmail.com mx
5 gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.
$ dig +short gmail-smtp-in.l.google.com aaaa
2607:f8b0:400e:c01::1b
$ telnet -b 2001:4830:1aff:8012::1 2607:f8b0:400e:c01::1a 25
Trying 2607:f8b0:400e:c01::1a...
Connected to 2607:f8b0:400e:c01::1a.
Escape character is '^]'.
220 mx.google.com ESMTP bc4si1505251pdb.237 - gsmtp
^]
telnet> q
Connection closed.
tcpdump:
00:29:50.064644 IP6 2001:4830:1aff:8012::1.45919 > 2607:f8b0:400e:c01::1a.25: Flags [S], seq 2164843936, win 14400, options [mss 1440,sackOK,TS val 1637141416 ecr 0,nop,wscale 5], length 0
00:29:50.109533 IP6 2607:f8b0:400e:c01::1a.25 > 2001:4830:1aff:8012::1.45919: Flags [S.], seq 703336991, ack 2164843937, win 42594, options [mss 1386,sackOK,TS val 2358118177 ecr 1637141416,nop,wscale 7], length 0
00:29:50.109576 IP6 2001:4830:1aff:8012::1.45919 > 2607:f8b0:400e:c01::1a.25: Flags [.], ack 1, win 450, options [nop,nop,TS val 1637141427 ecr 2358118177], length 0
00:29:50.156316 IP6 2607:f8b0:400e:c01::1a.25 > 2001:4830:1aff:8012::1.45919: Flags [P.], seq 1:54, ack 1, win 333, options [nop,nop,TS val 2358118223 ecr 1637141427], length 53
00:29:50.156343 IP6 2001:4830:1aff:8012::1.45919 > 2607:f8b0:400e:c01::1a.25: Flags [.], ack 54, win 450, options [nop,nop,TS val 1637141439 ecr 2358118223], length 0
00:29:51.556023 IP6 2001:4830:1aff:8012::1.45919 > 2607:f8b0:400e:c01::1a.25: Flags [F.], seq 1, ack 54, win 450, options [nop,nop,TS val 1637141789 ecr 2358118223], length 0
00:29:51.601307 IP6 2607:f8b0:400e:c01::1a.25 > 2001:4830:1aff:8012::1.45919: Flags [F.], seq 54, ack 2, win 333, options [nop,nop,TS val 2358119669 ecr 1637141789], length 0
00:29:51.601345 IP6 2001:4830:1aff:8012::1.45919 > 2607:f8b0:400e:c01::1a.25: Flags [.], ack 55, win 450, options [nop,nop,TS val 1637141800 ecr 2358119669], length 0
Both show that packets are coming through just fine...
Are outgoing port 25 TCP connections blocked?
 Shadow Hawkins on Monday, 12 October 2015 23:36:59
This problem has now been resolved, at least from my perspective.
Contrary to claims about port 25 not being blocked by SixSx or the SixXS PoPs, my tunnel has never been able to accept connections to this port from sites outside the SixXs network. After switching to another Tunnel Broker IPv6 connections to port 25 are now working fine. The only configuration change on my side of the tunnel was to change the IP addresses as appropriate for the new tunnel.
To me, this looks like fairly conclusive evidence that the uslax03 PoP was indeed blocking TCP connections to port number 25, at least for my tunnel. I don't need a fix for this anymore, this is intended as an FYI in case somebody else encounters the same problem.
Thanks,
Joachim
Are outgoing port 25 TCP connections blocked?
Really, we do NOT block ports.
If any kind of blocking is happening it is not happening on the PoP.
|
![[ch]](/s/countries/ch.gif)
on Saturday, 20 December 2014 18:36:50
Posting is only allowed when you are