Routing incoming traffic from HAproxy to endpoint over IPSEC VPN
-
I need to define an HAProxy backend over an (existing) IPSEC VPN. The backend seems unreachable and I can see the packets are going out on WAN instead of going into the tunnel.
I found this https://www.netgate.com/docs/pfsense/vpn/ipsec/accessing-firewall-services-over-ipsec-vpns.html but I'm unable to get it working.
Haproxy listens on WAN and then needs to proxy to an endpoint only reachable over the IPSEC VPN.
Any idea if it is possible to solve this routing puzzle?
Posted it earlier in packages subforum, but after realizing it's more a routing issue then a Haproxy issue, I'm posting here now, with some rephrasing.
Sorry for cross-posting... -
hey thats an interesting one
keep me posted on this one
nP -
You'll need to bind it to "any" for the listen interface, not just WAN.
For that routing trick to work, it has to be able to source traffic from the local interface which is a part of the IPsec P2, which is most likely LAN.
Alternately, you could bind haproxy to LAN and setup a port forward for WAN->LAN on the haproxy port(s) you need.
Remember: Upvote with the đź‘Ť button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp
thanks .... testin binding HAproxy to LAN not to WAN
didnt see this commin
NP -
@jimp said in Routing incoming traffic from HAproxy to endpoint over IPSEC VPN:
For that routing trick to work, it has to be able to source traffic from the local interface which is a part of the IPsec P2, which is most likely LAN.
But local VPN subnet is /24 and the LAN interface has a /16 with an IP outside of the /24
Can I set an alias especially for this purpose to the LAN interface so it has in IP in the local /24 VPN subnet?
-
Awful network design issues aside, if that is one large flat /16 directly on the interface, then yes, an IP alias VIP in the IPsec P2 should work.
-
Ouch, that hurts, especially if an authority like JIMP tells you that your network is awfully designed…
Let me explain what I’m doing: we have quite a lot of customers (80+), each with its own server behind the LAN interface of PFsense. Customer one is let’s say 10.200.101.1 and customer 2 is 10.200.102.1 etc. If a customer needs more servers it gets a .2, .3 etc, just like it was a /24 network. It is however a /16 network, because all customers servers needs access to Pfsense as their gateway. I don’t see any other way to accomplish this.
With almost all customers we have an IPSEC VPN. To prevent overlapping I use a /24 network here, e.g. 10.200.101.0/24. Also discussed here: https://forum.netgate.com/topic/146816/p2-subnet-overlap As l have no control on the remote subnets I use this method (/24) to make the local customer networks unique, at least for IPSEC, so the combination will not overlap and do not cause any confusion in Strongswan.What do think in particular is that awful in this setup? If you see a more elegant way to accomplish this I’m happy to hear, although It might be a bit off topic from the original subject…
-
You should never have a whole /16 on an interface. Each customer should be isolated on its own L2 (e.g. VLANs) with its own dedicated subnet on that VLAN and/or a transit subnet with their /24 routed to them over that. Then you'd have a separate interface for each customer on pfSense. Failing that, you could have them isolated on VLANs with an L3 switch/router between the customers and pfSense but still keep them isolated, for example.
As you have it now there is nothing stopping customer A from programming an address in customer B's subnet and communicating directly with them. There is no security or isolation there. Everyone can see multicast traffic for everyone else on the segment, too.
-
@jimp said in Routing incoming traffic from HAproxy to endpoint over IPSEC VPN:
You should never have a whole /16 on an interface. Each customer should be isolated on its own L2 (e.g. VLANs) with its own dedicated subnet on that VLAN and/or a transit subnet with their /24 routed to them over that. Then you'd have a separate interface for each customer on pfSense. Failing that, you could have them isolated on VLANs with an L3 switch/router between the customers and pfSense but still keep them isolated, for example.
As you have it now there is nothing stopping customer A from programming an address in customer B's subnet and communicating directly with them. There is no security or isolation there. Everyone can see multicast traffic for everyone else on the segment, too.
Inter-machines traffic is prevented by the local firewall on the customer machine.
I would be happy to do the isolation on a lower level, have tried that before however, with VLANs but that didn't succeed, probably because it's already a virtualized setup and the hosting provider already uses VLANs. Nested VLANS probably won’t work, I couldn’t make that work in any way.
And as it all virtual I don’t have control over hardware switches too nor can I put a switch in between.
Besides that, the customer has VERY limited access to the server dedicated to him. Only special purpose TCP ports are opened over the VPN to this specific server. There is no way a customer can RDP to “his” server or something like that and hop the neighbour. He has no control over it whatsoever, we control it and he can only access services we made available on it.hope that makes sense.
-
@wickeren said in Routing incoming traffic from HAproxy to endpoint over IPSEC VPN:
Inter-machines traffic is prevented by the local firewall on the customer machine.
You can't trust clients to self-police.
All it takes is one OS level vulnerability they can exploit on the client and the whole thing gets compromised.
I wouldn't trust it, but it's not my network, so *shrug*
