Access to LAN only *AFTER* ping.
-
Test/SSH server em0 (LAN) interface:
172.28.40.5.43427 > 172.28.35.18.22: Flags ~~,The SYN is making it to the SSH server and there's no reply. pfSense is doing what it needs to do.
It also looks like something is mangling checksums.
What else is between pfSense and the test SSH server? Virtual environment or something? I'd stop looking at pfSense and look at your LAN environment.
Thanks again for the reply.
This is exactly what's puzzling me. There's actually nothing between pfSense and the test SSH server aside from a Gigabit switch… On the LAN, everything works fine. It's only VPN clients that have this issue. And, as I'd mentioned, once I ping the server from the VPN client, everything works perfectly normally. What would pinging the server change?
I also tried to SSH to another system and got the same result. However, the same tcpdump command provided the following output:
23:35:54.621330 IP (tos 0x0, ttl 63, id 64751, offset 0, flags [DF], proto TCP (6), length 60) 172.28.40.5.51074 > 172.28.35.3.22: Flags [s], cksum 0x2c51 (correct), seq 2048624374, win 13800, options [mss 1368,sackOK,TS val 2062873 ecr 0,nop,wscale 6], length 0 0x0000: 4500 003c fcef 4000 3f06 9b8b ac1c 2805 E..<..@.?.....(. 0x0010: ac1c 2303 c782 0016 7a1b 86f6 0000 0000 ..#.....z....... 0x0020: a002 35e8 2c51 0000 0204 0558 0402 080a ..5.,Q.....X.... 0x0030: 001f 7a19 0000 0000 0103 0306 ..z......... 23:35:54.621368 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 172.28.35.3.22 > 172.28.40.5.51074: Flags [S.], cksum 0xdf41 (correct), seq 2236258252, ack 2048624375, win 28960, options [mss 1460,sackOK,TS val 2225200 ecr 2062873,nop,wscale 7], length 0 0x0000: 4500 003c 0000 4000 4006 977b ac1c 2303 E..<..@.@..{..#. 0x0010: ac1c 2805 0016 c782 854a 97cc 7a1b 86f7 ..(......J..z... 0x0020: a012 7120 df41 0000 0204 05b4 0402 080a ..q..A.......... 0x0030: 0021 f430 001f 7a19 0103 0307 .!.0..z..... 23:35:55.313989 IP (tos 0x0, ttl 63, id 64752, offset 0, flags [DF], proto TCP (6), length 60) 172.28.40.5.51074 > 172.28.35.3.22: Flags [s], cksum 0x2bed (correct), seq 2048624374, win 13800, options [mss 1368,sackOK,TS val 2062973 ecr 0,nop,wscale 6], length 0 0x0000: 4500 003c fcf0 4000 3f06 9b8a ac1c 2805 E..<..@.?.....(. 0x0010: ac1c 2303 c782 0016 7a1b 86f6 0000 0000 ..#.....z....... 0x0020: a002 35e8 2bed 0000 0204 0558 0402 080a ..5.+......X.... 0x0030: 001f 7a7d 0000 0000 0103 0306 ..z}........ 23:35:55.314020 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 172.28.35.3.22 > 172.28.40.5.51074: Flags [S.], cksum 0xde94 (correct), seq 2236258252, ack 2048624375, win 28960, options [mss 1460,sackOK,TS val 2225373 ecr 2062873,nop,wscale 7], length 0 0x0000: 4500 003c 0000 4000 4006 977b ac1c 2303 E..<..@.@..{..#. 0x0010: ac1c 2805 0016 c782 854a 97cc 7a1b 86f7 ..(......J..z... 0x0020: a012 7120 de94 0000 0204 05b4 0402 080a ..q............. 0x0030: 0021 f4dd 001f 7a19 0103 0307 .!....z..... 23:35:56.820451 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 172.28.35.3.22 > 172.28.40.5.51074: Flags [S.], cksum 0xdd1b (correct), seq 2236258252, ack 2048624375, win 28960, options [mss 1460,sackOK,TS val 2225750 ecr 2062873,nop,wscale 7], length 0 0x0000: 4500 003c 0000 4000 4006 977b ac1c 2303 E..<..@.@..{..#. 0x0010: ac1c 2805 0016 c782 854a 97cc 7a1b 86f7 ..(......J..z... 0x0020: a012 7120 dd1b 0000 0204 05b4 0402 080a ..q............. 0x0030: 0021 f656 001f 7a19 0103 0307 .!.V..z..... 23:35:57.309465 IP (tos 0x0, ttl 63, id 64753, offset 0, flags [DF], proto TCP (6), length 60) 172.28.40.5.51074 > 172.28.35.3.22: Flags [s], cksum 0x2b25 (correct), seq 2048624374, win 13800, options [mss 1368,sackOK,TS val 2063173 ecr 0,nop,wscale 6], length 0 0x0000: 4500 003c fcf1 4000 3f06 9b89 ac1c 2805 E..<..@.?.....(. 0x0010: ac1c 2303 c782 0016 7a1b 86f6 0000 0000 ..#.....z....... 0x0020: a002 35e8 2b25 0000 0204 0558 0402 080a ..5.+%.....X.... 0x0030: 001f 7b45 0000 0000 0103 0306 ..{E........ 23:35:57.309497 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 172.28.35.3.22 > 172.28.40.5.51074: Flags [S.], cksum 0xdca1 (correct), seq 2236258252, ack 2048624375, win 28960, options [mss 1460,sackOK,TS val 2225872 ecr 2062873,nop,wscale 7], length 0 0x0000: 4500 003c 0000 4000 4006 977b ac1c 2303 E..<..@.@..{..#. 0x0010: ac1c 2805 0016 c782 854a 97cc 7a1b 86f7 ..(......J..z... 0x0020: a012 7120 dca1 0000 0204 05b4 0402 080a ..q............. 0x0030: 0021 f6d0 001f 7a19 0103 0307 .!....z..... [/s][/s][/s] ```~~ -
No idea but since the SYN is going out to LAN, I'd look at something on the host. Maybe its local firewall or something. Maybe it's behaving differently for traffic originating outside its subnet.
-
Interesting… Thanks again for the reply.
I've also got some new and rather interesting updates for this. Any non-encrypted connections work just fine before pinging. So, all http, smtp, pop3, etc... services that are non-SSL or non-TLS work without any issue at all. What the hell is going on here? The further I look into this the more puzzled I become. It seems it is related to encrypted connections only.
-
What is the target host? Unplug it and test with something else.
-
Target host is the same host (172.28.35.18 - FreeBSD 10.1). I've removed it from the network and tried another host but I get the same result. Non-encrypted connections work fine while encrypted connections simply timeout (unless I ping the target first from the VPN client).
-
No idea.
-
Haha. You and me both! Perhaps the way I'm routing the traffic is incorrect? Should I not be using a static gateway/route from pfSense to do this? Perhaps viragomann's recommendation to use NAT instead might do the trick. I've tried to do that but I am unable to get it to route anything all to the LAN. Or maybe it's just some settings somewhere… I'm completely stumped.
-
You don't understand. The SYN packet was going out the LAN and nothing was coming back.
Maybe you should diagram your network out for us.
What static gateway/route from pfSense?
-
I do understand that, actually. I'm just not sure why.
To diagram it out a little:
pfSense firewall/gateway is 172.28.35.1 which is forwarding OpenVPN connections to my internal VPN server on 172.28.35.22. I also have a gateway and static route on the pfSense server that forwards all traffic on 172.28.40.0/24 (VPN subnet) to the internal VPN server at 172.28.35.22. Without this static route, the VPN clients are unable to hit anything on the LAN.
I'm wondering if running OpenVPN on firewall/gateway might be the better way to go. However, I cannot find any documentation on how to add create certs/keys which are revocable without adding users. In other words, I'd like to continue using the "easy-rsa" style OpenVPN setup. According to the documentation I've found, I'd either need to create a user for each Cert or a single, revocable CA (which would be silly if I have many users that don't want username/password auth (only certificate/key).
Some people seem to have accomplished this but when I attempt the same, there are no revocable certs. Only the main CA. I'm going to keep playing around with it and see if I can't get it to work.
-
No. Make a diagram. I don't even want to read that and do the work of diagramming it myself.
See the diagram in my sig for the type of information necessary.
-
Ah. Gotcha'. I'll have a diagram shortly.
-
Sorry for the delay. Got pretty busy at work. I've attached the diagram. It's a pretty simple setup.
-
Ok I don't understand at all. Where, exactly is the 172.28.40.0/24 subnet? On pfSense are you saying there's a route for 172.28.40.0/24 with a gateway of 172.28.35.22?
So when 172.28.35.5 needs to send traffic to 172.28.40.X it sends it to its default gateway, 172.28.35.1. That's where you get messed up because pfSense has to route the traffic back out the same interface it just received it on. That is unsound network design. Sometimes an ICMP redirect is issued telling 172.28.35.5 to send it's traffic again but to 172.28.35.22 instead. The same holds true for the return traffic. It's all going to be sent back to pfSense and have to be routed back out the same interface it came in on.
It's not surprising to me that you're seeing strange things. I would redesign your network such that your VPN server is on a different network segment as all your clients. and when they send traffic out to their default gateway, it doesn't have to route back out the same interface to get to any destinations.
Or just let pfSense do it.
-
Yes. You are correct. There is a gateway to 172.28.35.22 for all 172.28.40.0/24 traffic. Thanks for the info! This is exactly what I thought. I went ahead and moved the VPN server to the pfSense gateway and everything seems to be working as expected. Thanks again for all your replies and help. I certainly appreciate it.
-
I think your LAN hosts don't know the way to your VPN client and send their packets to the default gateway.
You should add a NAT rule to the VPN server, translating the source IP of packet from VPN clients to the servers LAN IP when they are going to LAN network.Thanks for the reply. On the firewall/gateway, I currently have an additional gateway setup (vpn server) and also a static route that points all VPN network traffic to the VPN server. Is this not the correct way to do it? Should I remove these and use NAT instead? If so, what would the proper way to add an NAT rule to translate the source be?
No. You need a NAT rule on your VPN server for fixing that, not on pfSense. A VPN server is also a router on the other side and should be able to do NAT.
The NAT rule must translate the whole traffic coming from VPN clients to the servers LAN IP (172.28.35.22). This way response packets from other hosts are addressed to 172.28.35.22 and enter the VPN server where they are translated to client IPs.
