Local traffic on a VLAN with a remote gateway
-
-
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…
