Policy Route Phone Through 2nd Wiregurd
-
Is it possible to policy route a phone connected to pfSense via wiregurad out of pfsense to the internet via another wiregurad connection to a vpn provider?
I have an android phone configured to connect to pfsense by way of wireguard which is linked to an interface called DMA_Remote on 10.0.9.0/24. The phone is peered to allow IP Addresses of 0.0.0.0/0 which works perfectly. I have no problem connecting to anything on my LAN. I had to set a NAT rule for it to be able to access the internet. This is the rule for that:
With the above rule I can access the internet from anything connected to the DMA_Remote tunnel. But when it does it is connecting to the internet via the WAN interface in pfSense. I want to direct the connection to the internet through a VPN provider connected to pfSense through another wirecuard connection. So I disabled the above rule and configured another NAT rule to allow my VPN provider's wiregurad address to allow 10.0.9.0/24 traffic through to the VPN provider like this:
After doing so I created a policy route by way of a firewall rule on the DMA_Remote interface as seen in the last rule in this picture:
I'm not sure what I missed but the combination of the NAT and Firewall rules above won't allow access to the internet. My phone is completed blocked from the internet.I'm not sure what I missed and would really appreciate someone's help.
-
@dma_pf Your last rule there is only policy routing udp traffic out the ivpn connection, you probably want that to be any protocol. And that last rule is also never going to be hit as the rule above it is an any/any pass rule so all traffic will be routed thru your default gateway before it hits that last rule.
So either disable the 2nd last rule or move the last rule up one and set it to match on all traffic, not just udp. That should do it.
-
@dma_pf In addition to what Slugger said, you probably want to add a source IP associated with the address(es) that the phone(s) would have in WireGuard (since you have to set up each peer in WireGuard, you should know what address(es) the phone(s) will have). Otherwise ALL traffic matching that rule (which if you make the UDP -> Any change Slugger mentioned would be any IPv4 traffic) will be sent to the VPN connection. If you will only have phones connected to this WireGuard tunnel, then you can ignore what I've said.
-
@Slugger After reading your post I realized that I had posted an incorrect picture of my firewall rules. I did a bunch of testing yesterday trying to figure this out and had been enabling and disabling the any/any rule multiple times to try to route things out through either the WAN or Wireguard. I inadvertently posted a picture of when the any/any rule was enabled. I apologize for that. Obviously it wouldn't work that way. You were absolutely correct in that the protocol had to be changed from just UDP. I switched it to TCP/UDP and it worked immediately. Which now has me confused as it is my understanding that wireguard only does UDP. I still don't understand why UDP by itself would not work and would sure like to know why.
@virgiliomi Thanks for your suggestion on limiting the source to particular IPs. The DMA_Remote tunnel will in fact be multi use with a mixture of phone, tablets and laptop peers needing different levels of access. Some will need access to internal networks and other's just out to the internet. I plan on locking this all down further now that I have it working and I appreciate you suggestions.
Thanks again to both of you for your help.
-
@dma_pf The traffic that is seen on the wg interface is the data that's been decrypted after wg has processed it. So this is your phone's web request to a web site on tcp/443, for example. This is the kind of traffic you're processing on this interface.
The udp only traffic is the actual tunnel itself, carrying the encrypted data. So on your WAN interface you have a rule that accepts udp only traffic on the wg port. All of this data is encrypted (the contents being your tcp/443 web request made by your phone). The wg port accepts that encrypted data, decrypts it and sends the decrypted packet onto the wg interface for processing (pass/block based on your interface rules).
If you setup the gateway to be another wg interface then the same process happens in reverse. Your incoming wg interface routes the decrypted packet to your outbound wg interface, which encrypts it, wraps it in a udp datagram and ships it across the outbound wg interface where your vpn provider receives, decrypts it, and so on.
-
@slugger I owe you a debt of gratitude for your last post. You have tremendously clarified my thoughts and helped me resolve some long standing questions/misunderstandings/uncertainties that I've had with regard how VPN's work. I'm sure that the knowledge you passed on to me in your post will benefit me for years to come. Thank you, very, very much!