@kom Hey I just wanted to follow up and let you know for posterity that I discovered the solution.
Simply setting each subnet/interface's allowed gateway on the firewall wasn't enough. The traffic MUST BE TAGGED in a floating rule.

So basically here is a summary for anyone who might be searching for this:

Goal: Route different traffic to specific gateways, only allowing in/out on specific interfaces or subnets. I have one WAN interface and two LAN interfaces: one of which should ONLY be to VPN (can be single gateway or gateway group), and the other should ONLY be through ISP.

Add firewall allow rules on each interface.

LAN to ISP only
45624255-c3b2-4e88-b5de-0670de19f825-image.png

LAN to VPN gateways only
4e7095d3-3ae7-4768-abae-33aee2e46f3b-image.png

In each rule, tag the traffic with a name you choose:

1bbbdcd6-e3ef-4738-a9a6-7c89ae21ac2f-image.png

7757ab98-6727-4c3a-9385-e434b2a85d82-image.png

Add two floating BLOCK rules.

bb7d5327-6a24-47c2-9d1d-f5c5866008c7-image.png

When you set the block rules for each inbound interface (WAN and VPN), set the opposite tag in the "tagged" field.
This will refuse any packets that have matching tags.

This is what finally stopped any detection of incorrect traffic on either gateway.

Thanks for your help though.

@serbus

That seems to have fixed it.

Thanks!!!

@beartm yeah sorry to bring this thread back to life but it was exactly what i'm trying to do!

so how do you route certain traffic through pfsense or does all your traffic go through it? i was trying to setup socks5 proxy so i can configure it in certain applications and then i know all traffic from that application is using it and then going through the VPN (i've forced all traffic via the VPN on my pfsense box).

@oldschoolrouterjockey said in Why assign an OpenVPN connection as its own interface?:

OK so I figured out the last parts to make this all work:

I knew it was all there in the descriptions, but if you work hard to succeed, you'll know how to do it next time 😉 😉 😉

@ensnare I know this is an old thread but I found it via search, so thought I'd update for anyone else that lands when looking for this message. There's a workaround here that might help:

https://forum.netgate.com/topic/149636/problem-with-automatic-filter-reload-when-openvpn-is-in-a-gateway-group/5

@viragomann

Yep, I do not disagree however note:

The interfacegroup function is probably sufficent for this issue. However in other situations I would love an option to define a group of rules which could be 'included' in a set of rules for a certain interface as 'one virtual rule'

Related to 853 query's, I agree that it is perhaps better to block them, assuming the resolver is also not capable to see the destination (I am not 100% sure about how that is implemented. If !???? the resolver can decode the SSL, then 853 should be allowed)

And yep since the resolver act as a DNS-proxy, I agree that telling the resolver that it should use 853 to query the upstream DNS.

@viragomann said in Failover doesn't work.:

@darkcorner said in Failover doesn't work.:

pfSense used until yesterday 8.8.8.8 on the WAN1 NIC and 8.8.4.4 on the WAN2 NIC.

Is there any reason for binding the DNS servers to a specific interface?

Also this servers are only used by the DNS Forwarder or by the Resolver if it's in forwarding mode. And apart from this, on pfSense itself.

Because in the General Setup/DNS Server Settings, I see: "When using multiple WAN connections there should be at least one unique DNS server per gateway."

@panja You can't use Unbound on Pfsense on all interfaces if you want to avoid DNS leaks, the reason is that it's the firewall which is performing the DNS forwarding to upstream DNS - not your client. In this instance the requests will exit the firewall on any of the external interfaces unbound sends out on. Your client being part of a VPN is irrelevant.

I have tackled this myself though and my setup is set to use DNS on 853 for non-vpn connections using Unbound, but then for VPN clients I have a Port Forward rule at the top of the interfaces which intercepts DNS traffic and redirects it away from Unbound and towards Cloudflare (that rule it's self has the VPN Gateway as it's gateway).

Here is an example Port Fwd I set up:

Source - ALIAS Group for my VPN Clients.
Destination - XXXX_Address (Address of the firewall interface in question)
Redirect Target IP - Single host, but an alias group is added. This Alias group contains the CloudFlare IP's.
Destination and Redirect Ports are DNS.

Create a filter rule association and it'll add a rule to the interface in question. Edit that rule to make sure it uses your VPN as the Gateway and away you go. By doing this you are forcing your client as part of the VPN to forward DNS over the tunnel as opposed to Unbound, so DNS queries will always remain in the tunnel.

Obviously you don't need to use an Alias group if you want all traffic to be subjected to this, you could just change the source to the net of the interface you are working on, which is what I've done on my Captive Portal VLAN for Guests. I personally prefer to use Alias groups on my main VLAN's though as it provides a bit more flexibility.

Express VPN on their UK and US tunnels report no DNS leaks with this method as it comes out of the tunnel using their DNS, but some of the smaller VPN's in Europe and Asia still report leaks as it's seeing CloudFlare DNS, but you'll notice that even in this scenario the CloudFlare IP is the nearest host to the tunnel endpoint in question, rather than your own WAN - so that's still not a leak.

For completeness I also used the Tagging method within pfsense to create a kill switch as such, so on both my main 'VPN' Any Rule and the DNS intercept rule I have a Tag called VPN_ONLY.

As a floating rule I've then created a block on both my WAN Circuits should traffic arrive with the VPN_ONLY tag. It avoids the situation of leakage if the VPN goes down and the clients try using another gateway on the next rule etc.

@drunk_am_i Add them as virtual IPs, then you can either use NAT port forwards or 1:1 NAT to direct inbound Internet traffic to your private IPs. 1:1 also sets up the outbound NAT as noted on the 1:1 doc page.

@tve Not sure if your Dyn DNS is updating google hosted external DNS, but I'm wondering if this fix may help you:

https://redmine.pfsense.org/issues/12754

I had similar problems to you with similar requirements. I found the DynDNS change to be very inconsistent and delayed, certainly on the WAN was failing back, I also experienced a painfully slow loading of the dynamic DNS page (to the point where i'd have to close my browser and start again).

The fix details (as it's google specific) doesn't suggest it would have fixed all the problems I was having, but I cannot ignore the fact that I no longer have those inconsistent issues since applying it.

I applied it via the Systems Patches package, you can select it from the recommended patch list to save you manually fiddling with files etc.

@reg_ed said in How to add wireless VLANs through additional router:

Can I buy you a beer?

While I would love that if you happen to be in the chicagoland area ;) Best way is just pay it forward, if you can help someone in anyway - please do so, be it tech help here on the forums or other forums, or even buying a homeless guy a coffee or sandwich.. (or beer - which they prob enjoy more)! ;)

Any device needs a gateway or a specific route on how to talk to something that is not on its local network. Or it just don't know where to send the traffic to get back to that network. If the device doesn't know how to get to the source network of the traffic, you can just kind of trick it via the nat, that device wanting to talk to it is local.

Just like internet wouldn't know how to talk to your rfc1918 and your router nats it to what your public IP is that you get from your isp.

@darkcorner I think you're looking for policy routing.

@odhiambo said in Alias Public IP:

not the right way since you say that "pfSense knows the 197.232.xx.64/30 subnet is on OPT1".

I was assuming this was a second public static IP. If they route it to your first public IP, then 97.232.xx.65 would go on OPT1 and the server plugs into OPT1. (or whatever interface, that isn't LAN)

If they are not routing the new subnet as the above linked doc page describes then I guess you'd need to set it up on pfSense WAN as you did and use 1:1 NAT to send it to your server on LAN.

@viragomann and @lawrencesystems

https://www.youtube.com/watch?v=tHfAWY_jYbQ

Thank you!