Local traffic on a VLAN with a remote gateway
-
How can I configure a network to have a remote gateway (0.0.0.0/0) but still allow connectivity to other local networks? Is it really either/or?
-
so you want to send all traffic down the vpn of a client. But you want him to be able to access other local networks via his normal gateway of that local network.
So lets say your client is on on his local network
10.0.0.0/24 with normal gateway of 10.0.0.1/24, he then creates a vpn into your network and you default him down the vpn.. So now for him to get to 10.0.1/24 he thinks he needs to go down the vpn vs going to the 10.0.0.1 gateway to get to 10.0.1/24
If that is what your asking, just need to create a host route on this client to say hey to get to 10.0.1/24 talk to 10.0.0.1 - this is more direct route vs his default gateway of going down the vpn and therefore the client will use that route over the default 0.0.0.0 route.
If you can give more specifics we can get into greater detail if needed.
-
Let's say I have two VLANs on router A; 10.0.1/24 and 10.0.2/24. The second VLAN has a site-to-site VPN with 0.0.0.0/0 as the right side; a remote gateway. All traffic from hosts on the 10.0.2/24 network goes over the VPN and NATs out from router B. However, from a computer on 10.0.1/24 I want to reach a server on a 10.0.2.x address for management/updates. Is there some sort of split tunnelling, tunnel network exception or even a order of operations change that can allow the two local networks to reach each other again?
-
So these are vpn clients on pfsense?
So you have the attached? You have a client in this 10.0.2/24 network that points to a different gateway than pfsense.. Or your doing policy routing on pfsense? If so I am confused about where the vpn comes in?
If your setup is like 1st then you would need host route on the box in 10.0.2 network to tell it to get to 10.0.1 talk to the IP of pfsense on the 10.0.2 network.
If your setup is like 2nd drawing with policy routing, it should work just fine if 10.0.1 is creating the connection. If box on 10.0.2 is wanting to talk to 10.0.1 and he starts the conversation then you would need rules above where you policy route it out the vpn connection.
I always say a picture is worth a 1000's words - so simple drawing of your network would go a long way in helping you solve your problem.
-
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:
-
"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.
-
Ah.. Yeah that is a problem…
© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy