Hello all,
I am currently working in setting up a new network for third parties to reach some of our internal systems through dedicated lines. The idea is to use OpenBGPd+PF+CARP to have a fully redundant solution. My current configuration is explained in the attached files.
The problem is that when I try to connect to some server in the 10.100.0.0/24 network, PF never goes from SYN_SENT to ESTABLISHED, although tpcdump(8) shows that all handshake packets have passed.
For example, when I try a ssh connection to 10.100.0.1 here is what
inbound interface tcpdump:
outbound interface tcpdump:
And to have a better prove that I have a TCP circuit in place, the ssh client gives me a working prompt, at least while the 30 seconds that PF holds the SYN_SENT connection in the state table.
The strangest thing, is that connections coming from inside the 10.100.0.0/24 network works as expected and if I move to static routes everything works properly.
Might be a kernel or PF bug?
I am currently working in setting up a new network for third parties to reach some of our internal systems through dedicated lines. The idea is to use OpenBGPd+PF+CARP to have a fully redundant solution. My current configuration is explained in the attached files.
The problem is that when I try to connect to some server in the 10.100.0.0/24 network, PF never goes from SYN_SENT to ESTABLISHED, although tpcdump(8) shows that all handshake packets have passed.
For example, when I try a ssh connection to 10.100.0.1 here is what
tcpdump
and pfctl
tells me.
Code:
sudo pfctl -ss | grep -A 3 ":22"
...
[B]all tcp 10.100.0.1:22 <- 10.120.200.18:50301 CLOSED:SYN_SENT
all tcp 10.120.200.18:50301 -> 10.100.0.1:22 SYN_SENT:CLOSED[/B]
...
inbound interface tcpdump:
Code:
tcpdump: listening on vlan2, link-type EN10MB (Ethernet), capture size 65535 bytes
00:00:00.000000 00:22:19:7a:99:57 > 28:80:23:ac:7c:f4, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 126, id 7886, offset 0, flags [DF], proto TCP (6), length 52)
10.120.200.18.50336 > 10.100.0.1.22: Flags [[B]S[/B]], cksum 0xa101 (correct), seq 445641177, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.002445 00:22:19:7a:99:57 > 28:80:23:ac:7c:f4, ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 126, id 7887, offset 0, flags [DF], proto TCP (6), length 40)
10.120.200.18.50336 > 10.100.0.1.22: Flags [[B].[/B]], cksum 0x723d (correct), ack 464351962, win 256, length 0
00:00:00.014019 00:22:19:7a:99:57 > 28:80:23:ac:7c:f4, ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 126, id 7888, offset 0, flags [DF], proto TCP (6), length 68)
10.120.200.18.50336 > 10.100.0.1.22: Flags [P.], cksum 0x7d0b (correct), seq 0:28, ack 1, win 256, length 28
...
outbound interface tcpdump:
Code:
tcpdump: listening on vlan1620, link-type EN10MB (Ethernet), capture size 65535 bytes
00:00:00.000000 28:80:23:ac:7c:f4 > 00:0c:29:bd:86:05, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 125, id 7886, offset 0, flags [DF], proto TCP (6), length 52)
10.120.200.18.50336 > 10.100.0.1.22: Flags [[B]S[/B]], cksum 0xa101 (correct), seq 445641177, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.002421 28:80:23:ac:7c:f4 > 00:0c:29:bd:86:05, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 125, id 7887, offset 0, flags [DF], proto TCP (6), length 40)
10.120.200.18.50336 > 10.100.0.1.22: Flags [[B].[/B]], cksum 0x723d (correct), ack 464351962, win 256, length 0
00:00:00.013995 28:80:23:ac:7c:f4 > 00:0c:29:bd:86:05, ethertype IPv4 (0x0800), length 82: (tos 0x0, ttl 125, id 7888, offset 0, flags [DF], proto TCP (6), length 68)
10.120.200.18.50336 > 10.100.0.1.22: Flags [P.], cksum 0x7d0b (correct), seq 0:28, ack 1, win 256, length 28
00:00:00.033068 28:80:23:ac:7c:f4 > 00:0c:29:bd:86:05, ethertype IPv4 (0x0800), length 726: (tos 0x0, ttl 125, id 7889, offset 0, flags [DF], proto TCP (6), length 712)
10.120.200.18.50336 > 10.100.0.1.22: Flags [P.], cksum 0x373d (correct), seq 28:700, ack 22, win 256, length 672
And to have a better prove that I have a TCP circuit in place, the ssh client gives me a working prompt, at least while the 30 seconds that PF holds the SYN_SENT connection in the state table.
The strangest thing, is that connections coming from inside the 10.100.0.0/24 network works as expected and if I move to static routes everything works properly.
Might be a kernel or PF bug?