Route inbound WAN traffic to server on remote tunneled network
-
johnpoz ... Actually, upgraded to 2.4.4 yesterday and began playing with VTI. However, haven't been able to get the PHASE 2 SA's to build using VTI.
Regarding the port forward:
On going directly to the cradlepoints: These travel from stadium to stadium and are always provided internet connectivity ... but never directly. And they are always behind very highly secured firewalls. Establishing the VPN is possible, but reaching it directly is not. I did think about trying to relay through Azure or something, but not sure that is much different than this.
Thanks for your assistance on this.
-
That should work without VTI provided you use a P2 for 0.0.0.0/0 on the pfSense end. That also means it will send all of its Internet traffic back through your side, though.
Otherwise the port forward traffic will be forwarded across the VPN by pfSense and then the remote device will send the replies back out its WAN.
There may be a way to rig something up with a local instance of a bounce or proxy daemon to work around that. If it's a TCP service maybe use haproxy, then Internet hosts hit haproxy, haproxy makes a new connection to the remote device, then it will reply back to the firewall which can relay the replies back to the client.
-
@jimp I would only want that port being forwarded to traverse the tunnel as it is only up during GameDay. It is dead 99.9% of the time. Wouldn't pfsense write a route to the 192.168.200.x to the tunnel endpoint. That is how it routes traffic from the LAN.
-
This is a very interesting use case.. If I get a chance I will try and duplicate this... I have some vps I should be able to bring up a ipsec tunnel with. And then forward traffic through from public internet and hit the vps service.
I am wondering if part of the problem is going to be the other cradlepoint side where why would it route the return traffic back through the tunnel. Lets say your coming from public IP 1.2.3.4 and hitting your pfsense on port 9002, pfsense fowards this down the tunnel and you hit the service behind the cradlepoint... The service answers back to 1.2.3.4 - but why would that go back down the tunnel.. Wouldn't it just go out the default wan gateway on the cradlepoint.
Maybe if you setup the tunnel so that the cradlepoint knows to go back through the tunnel to get to 1.2.3.4.. Just spitballing here.. I don't recall ever having to do something like this before - but the source IP could be a problem. For the return traffic off the top of my head.
@Derelict for sure would be of great help in such a setup
-
Traffic still has to match the P2 to enter or exit the tunnel, and the far side still has to send the replies back the way they entered. The only way to make that happen properly with tunneled IPsec is with a P2 for 0.0.0.0/0 to the device.
EDIT: And with VTI the far side still has to send the reply back the right way, which won't happen without something like
reply-toin pf which who knows if cradlepoint has anything like that. -
@johnpoz You may be right with the Cradlepoint not returning traffic, I haven't been able to get traffic to it yet to see. When i capture the IPSEC tunnel on the far end, i don't see any traffic unless i originate from the near end LAN.
-
I am probably in way over my head here, but would it be possible to use OpenVPN? I'm pretty sure you can accomplish the reverse route with an iroute statement in the client specific overrides on the server side.
-
@bfeitell I don't know much about OpenVPN, but I believe it takes a client app on the far end, correct? One of the limitations on this is that the device I'm trying to reach is a hardware device, not computer. So the router at the far end has to make the connection.
-
It works great on pfSense with OpenVPN on both ends, you can port forward across and on the remote side you can have an assigned OpenVPN interface which will send the replies back because
reply-toworks fine.But the remote here is a cradlepoint device so...
-
Pretty sure cradlepoints supports both openvpn as server or client.
https://knowledgebase.cradlepoint.com/articles/Support/Series-3-OpenVPN-Client-Server-Configuration -
@johnpoz said in Route inbound WAN traffic to server on remote tunneled network:
Pretty sure cradlepoints supports both openvpn as server or client.
https://knowledgebase.cradlepoint.com/articles/Support/Series-3-OpenVPN-Client-Server-ConfigurationSure but it would also need something like
reply-toor the replies will go back the wrong way (out the cradlepoint WAN) -
Not sure on that...
Couldn't you just have the cradlepoint bring up another ipsec tunnel to your other location?
-
@johnpoz The Cradlepoint is a MBR1200v1 ...unfortunately, it doesn't support the OpenVPN. I am checking into whether we can obtain an MBR1400. It sounds from reading through the VTI info that it would indeed function just like an interface. I need to continue experimenting with that and why I can't get the SAs to come up using VTI.
I'm guessing the reason "tunnel" mode won't route from the WAN is the SPD that is being written:
This is allowing traffic through the tunnel from my endpoint to the far endpoint provided it's source is 192.168.0.0/18.
-
what about just bring up another ipsec tunnel to the other location(s) that would need to access?
