Local traffic on a VLAN with a remote gateway
-
Definitely like the second drawing. pfSense on both sides. I sent an email with a few more specifics.
I don't believe this is how pfSense should behave, but I don't have any spare Cisco gear to replicate my setup using a different router.
If you want to test, however, I could lend a cloud instance.
-
If your setup is like drawing 2 - out of the box you would be able to access stuff on 10.0.2 from 10.0.1.. Other than local firewalls on the devices in question.
Policy routing devices on 10.0.2 to a gateway has nothing to do with connections from 10.0.1.. Now if you do not allow access in the rules on 10.0.2 to 10.0.1 then 10.0.2 clients would not be able to create connections to 10.0.1 - but they for sure could answer to 10.0.1
Your not changing the gateway on the 10.0.2 client, or running a vpn client on that device directly are you? You sure do not need to nat these clients to your vpn IP, as long as the other end allows and understands how to get back to this network via the vpn, etc.
Please show your outbound nat rules and your policy routing, ie your rules on your 10.0.2 interface.
-
For the sake of testing, both interfaces have rules that allow their subnet anywhere. If I disable the VPN then the hosts can reach other, but as soon as the VPN is enabled that stops.
-
It's worth noting that I've done remote gateways a few times on a few different pfSense instances with the same behavior over the past few years. I've made workarounds by creating an IP alias on the network with the remote gateway and added secondary IPs on the servers on that VLAN, with routes applied that backchannel the local networks. It's messy and impossible to do with iPhones and other devices I'm using now.
-
If you are policy routing to the VPN you have to bypass said policy routing for local subnets:
https://doc.pfsense.org/index.php/Bypassing_Policy_Routing
-
"I've made workarounds by creating an IP alias on the network with the remote gateway and added secondary IPs on the servers on that VLAN"
What???
Dude post your freaking rules please… If you set a gateway on your 1 rule then no your not going to be able to get to your other network... Put a rule above it that allows access to the other network before you send traffic out a gateway.. The link Derelict points to goes over this.
-
The bypassing policy routing makes sense if I had other rules with different gateways, which I don't. It's just a VPN with 0.0.0.0/0 as the remote side.
How do I create a remote gateway using routing? IPSec isn't an available interface to apply the gateway on.
-
-
I hand out VLANs like Oprah hands out gifts and I also block all traffic to and from the DPRK.
-
dude your blocking access to LAN net - so yeah NO shit your not going to be able to go there!!! And all your other nets!!
-
Trying to reach it from "Desktop"
I can access it if I disable the VPN. -
And what is your desktop rules?
-
Wide open:
-
IPsec to destination 0.0.0.0/0 is a significant hurdle. That is generally reserved for things like mobile IPsec clients.
Your reply traffic from the PROXY network is probably going out that IPsec tunnel since it matches the traffic selector there.
A simple packet capture on the IPsec interface should confirm.
-
How should I be setting it up? Rules for the local subnet(s) with no gateway specified and then a catch-all for everything else could work, but what do I set that gateway to?
-
I can't think of a good workaround.
Like I said, IPsec to destination 0.0.0.0/0 is troublesome if that is not really what you want. And in your case it is not what you want because you want to carve out exceptions to that.
-
So I should submit a bug then, right? More of a new feature I guess.
We are able to do this with Cisco ASAs btw. It's not like I'm just making up networking concepts.
-
Not a bug.
When we get routed IPsec in 2.5-ish it might be possible.
Use an ASA then I guess. FreeBSD IPsec traffic selectors work how they work at this time.
-
@derelict not getting why this should be an issue.. There are direct routes in play for the local networks - why would it force it down the tunnel.. Should only go do the default route tunnel if there is no more direct route.
@fauxshow - why not just do with openvpn vs ipsec? Then you do a simple policy base routing.
-
Because the traffic selectors are hit before the routing table. They have no concept of states or anything like reply-to.
He has a selector source PROXY net dest any (0.0.0.0/0).
Reply traffic matches that so that's where it goes.
