Access to LAN only *AFTER* ping.
-
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.
