Wierd firewall rules blocking traffic
-
Have you tried adding a rule allowing traffic from 10.8.* back into the LAN?
-
Nope, I could try that.
-
Src 10.8.0.0/24 to LAN did not make the thing to work.
I believe it's definitely a bug or something as for the first few seconds it's working properly, but after some times the firewall start blocking even if the rules said it shouldn't. -
Are you connecting to your vpn server using your public IP or private IP? Usually traffic originating from the inside of your network leaving your network then trying to come back in is blocked. Not really sure why this ever worked. All firewalls have this behavior that I have seen.
-
Connection between VPN Client and VPN Server are using public IP to create the tunnel between each others.
After that, and since the VPN Client is in my private network (192.168.1.0/24), I redirect all traffic to destination 10.8.0.0/24 from 192.168.1.0/24 to 192.168.1.254 (VPN Client), the VPN client then redirect all traffic to it's VPN gateway.
That mean all computer on 192.168.1.0/24 (expect 192.168.1.254) will transmit packets to pfSense (192.168.1.1 and if the destination is 10.8.0.0/24) which will redirect this traffic to 192.168.1.254. From now on, 192.168.1.254 has is own route telling that the default gateway is the VPN one.
As said, the first 10-15-20sec are working correctly, but then suddenly I'm getting blocked by the firewall (LAN to 10.8.0.0/24) even through it was working the first 10-15-20 first second.
Also, as said before, if I directly add the following route (dest 10.8.0.0/24 mask 255.255.255.0 gateway 192.168.1.254) to each computer in 192.168.1.0/24, the link is working properly but it's not passing through pfSense LAN Interface. That mean I need to configure every single computer in 192.168.1.0/24 to add the said route. Hence why I want to direct traffic to default gateway (pfsense) that will handle were to send traffic after that (192.168.1.254). -
I get what your saying now, you want to use your VPN client to route traffic from your LAN to the remote Network. I was half sleep when I first read your post. There are two things think about:
1. First on your LAN rule I would change the source from LAN subnet to Any.
2. Second is remember in order for routing to work properly it is not enough for you to send traffic to the remote network. The remote network needs to have a route back to your network. Not sure if you are in control of the distant end but you would need to make a router interface on the distant end and set up a static route to send traffic back.
Now if you are running a dynamic routing protocol on the your VPN client this could fix your issue. One solution could be that instead of routing the connection through your client maybe you can turn your client into a NAT that way the distant end doesn't need any knowledge of your private LAN. Like I state in my previous post I'm surprised you were able to get any traffic in the return direction at all.
A lot of people and sometime even me forget and think that if we send traffic to a router is will send the traffic back in the same interface that it came on but in fact a router will look at it's routing table to make the calculation on which interface to send the traffic on. If it doesn't have a route it will choose it's default route or discard the packet.
In summary if I'm understanding you correctly you are looking to make a site to site VPN using your VPN client instead of Server to Server. Sounds like a fun (hard) problem to work on. I hope I have added something useful for you to think about.
-
The routing is asymmetric - reply packets from the server 10.8.0.1 arrive at the VPN client on the LAN, and that machine delivers them directly to the LAN computer they are addressed to - pfSense never sees the reply/reverse-direction packets. And so after some time the state/flow that it initially established in pf is discarded. Then further packets you send that would have matched that flow are dropped by pfSense - that is why you get response for 10-20 seconds then it dies.
I think you can choose from:
a) In the rule that selects and direct traffic to this VPN, select advanced state type "sloppy state"; or
b) System-Advanced-Networking - "Bypass firewall rules for traffic on the same interface" - this should let anything through from LAN clients that goes back out LAN to get to the VPN link;It is also possible to use Manual Outbound NAT and NAT the traffic from your LAN clients back out the pfSense LAN to the VPN. Then the trafffic to the VPN looks like it comes from the pfSense LAN IP. Thus the response packets come back to the pfSense, which can keep track of the state/flow, "unNAT" them, and deliver them to the real end-client. A disadvantage of this is that the real end-client IP is hidden from the end-server, so you do anything special at the end server based on the incoming IP address.
Other option (cleaner IMHO) is to make the OpenVPN client originate from the pfSense - then all the routing, filtering, state tracking… happens consistently in 1 place.
-
The routing is asymmetric - reply packets from the server 10.8.0.1 arrive at the VPN client on the LAN, and that machine delivers them directly to the LAN computer they are addressed to - pfSense never sees the reply/reverse-direction packets. And so after some time the state/flow that it initially established in pf is discarded. Then further packets you send that would have matched that flow are dropped by pfSense - that is why you get response for 10-20 seconds then it dies.
I think you can choose from:
a) In the rule that selects and direct traffic to this VPN, select advanced state type "sloppy state"; or
b) System-Advanced-Networking - "Bypass firewall rules for traffic on the same interface" - this should let anything through from LAN clients that goes back out LAN to get to the VPN link;It is also possible to use Manual Outbound NAT and NAT the traffic from your LAN clients back out the pfSense LAN to the VPN. Then the trafffic to the VPN looks like it comes from the pfSense LAN IP. Thus the response packets come back to the pfSense, which can keep track of the state/flow, "unNAT" them, and deliver them to the real end-client. A disadvantage of this is that the real end-client IP is hidden from the end-server, so you do anything special at the end server based on the incoming IP address.
Other option (cleaner IMHO) is to make the OpenVPN client originate from the pfSense - then all the routing, filtering, state tracking… happens consistently in 1 place.
Thanks, I though of something like that was causing the blocking process, though I couldn't explain why, now I understand.
Your response is quite self explanatory.I've tried to use OpenVPN as a client durectly on pfsense, but somehow, I've never managed to make it work properly. The connection between pfSense (VPN client) and the server (VPN Server) was OK, pfSense computer was able to ping to the vpn server (10.8.0.1). But sadly and even if the rules/gateways I did create seemed correct (following multiple tutorials), no computer in the 192.168.1.0/24 network was able to reach the 10.8.0.0/24 network at all, expect pfSense itself.
Hence why I moved to a more "simple" configuration.Edit: "sloppy state" work perfectly
So, I assume in "sloppy state" pfSense doesn't wait for ack and keep the thing routing no matter what, correct ? Is there any draw back using "sloppy state" ? -
I'm thinking NAT is your only solution here's why. If your LAN sends a packet to a computer on the VPN LAN that client will receive it. Process it and send it back. When the packet gets created by the host on your VPN LAN it will see that the destination IP is not on it's LAN and therefore has to use it's Default Gateways Layer two address to complete the packet. When the router on your VPN gets the packet it will have no knowledge of your PfSense LAN and therefore discard the packet. If you have control of the VPN network you could create a static route back to your VPN client that would fix the issue.
Another issue I have with your set up is just because you have a client with connections to two different LANs doesn't mean that traffic will route from one to another (Not familiar with Asymmetric routing). So I'm assuming that you did something to your VPN Client to tell it that when you get traffic from one interface bound for the other to "route" it out the other interface? I'm sorry if I'm being picky about the details but I'm think about anyone else reading this thread for future reference. What I'm saying to be clear is that you would have to turn routing services on your client machine to get traffic to flow from one interface to another. This is how it is done in the Windows world which is what I'm most comfortable with. Please feel free to slap me if this is not the case in the Linux or Unix world. I would imagine it is the same otherwise this would represent a serious security flaw.
Lastly even if you turn your client into a router you would still have to get the other clients on the VPN network to use it and the only way to do that is to run a dynamic routing protocol like RIP, or OSPF; but obviously both routers would have to participate which would mean that you need to be in control of the remote network. Or like I mentioned above turn Nat on the VPN client so that is looks like all the traffic comes from VPN Client so the distant end never needs to know about your PfSense LAN.
I have thought of doing something like this so that I can connect my home network to my jobs corporate network but then decided not to do it because it would violate the companies "Network acceptable use policy" and also the security concerns that would come up from such a configuration. Like I mentioned before it is a fun puzzle though.
Phil.Davis mentioned making the VPN connection from PfSense which I would agree with however using OpenVPN would mean that your VPN Server is using OpenVPN correct? If it is using something like PPTP or IPSec you would need to use one of those instead. Which is probably why you went the VPN Client route.
To sum all this up I don't think that all your problems are on the PfSense side there are somethings that need to be done on your VPN network side as well unless I have completely missed the mark on this one or you go the NAT route.
-
It's actually working properly when modifying the rule redirecting traffic from 10.8.0.0/24 to the VPN gateway by using sloppy state.