redirect external port to openvpn IP client device
I have had this working before now but dont seem to be able to get it going again.
I have PFsense as my main box and a 4G openvpn client router. the vpn is up and running all good.
However i want to forward a port from my PFSense external IP to a client on the otherside of the openvpn session.
so EXT IP --> PFSense --> OpenVPN Client
Any help appreciated.
viragomann last edited by
Which openvpn type is it? Is that a site-to-site configuration or a remote access server? TLS, user auth, preshared key?
When you port forward/NAT from arbitrary source addresses to a destination across an OpenVPN tunnel You must assign an interface to the OpenVPN instance on the destination side and be sure that the traffic related to the port forward/NAT IS NOT matched by rules on the OpenVPN tab but IS matched by rules on the OpenVPN assigned interface tab.
Otherwise reply traffic from the target host is routed according to the routing table there as it does not have reply-to on the states which routes the reply traffic back out the interface into which the originating traffic arrived - the OpenVPN tunnel in this case.
frank451 last edited by frank451
still struggling with this.
can anyone give me an example?
I had already assigned the VPN Connection to a new interface. Tried doing a NAT rule to the VPN address. Do i use the source address as WAN still? Tried different variants and creating just rules and not NAT to no avail.
Cant understand why it aint working, as i had it working on an old installation.
I have allow all on the VPN interface rules
Hope some one can help as going on honeymoon soon in our campervan and need to port forward from my Work IP to the VPN in the camper.
The traffic CANNOT match rules on the OpenVPN tab. It must ONLY match on the assigned interface tab else you won't get reply-to.
When I do this stuff I just delete or disable all the rules on the OpenVPN tab and only use rules on assigned interfaces.
@derelict thanks for your prompt response again.
I'm just not getting it :-) :-( Back to basics if you could assist?
I have the following.
WAN, LAN, OPT1(VPN) all enabled.
WAN (Standard + any NAT port forwards listed to my local PFSense LAN)
Allow All - Does this rule need removing?
Now to the the rule
Do i create a NAT rule, or just put a standard rule in one of the interfaces under the firewall?
My EXT IP ---> ???? ---> 192.168.7.200 (on the VPN)
Internal LAN is 192.168.5.xxx
Hope you can assist
None of that makes any sense to me.
Use this diagram to describe your problem. Please be specific.
Ta, i'll do my best.
OpenVPN Remote Access (SitetoSite) (In my case 192.168.7.0/24)
WAN IP 88.x.x.x (ISP Address)
PFsenseA (internal LAN 192.168.5.254/24)
What i need to achieve is when i enter http://88.x.x.x:18990 in web browser it wil then direct the incoming traffic request to 192.168.7.200 (device on the sitetosite connection)
I can communicate with all devices across all subnets from and to any VPN and from and to VPN - VPN (other connections), so traffice wise everything is right, i just can get the port 18990 forwarded to a vpn deivce end point from my PfsenseA WAN IP
Hope that helps
Please just describe your problem as if the scheme presented is your network. I don't know wtf http://88.x.x.x:18990 is.
Device on internet connection be it a PC or mobile device inputs the http request to WANIP port 18990 to pfsenseA
PFsenseA then says ohhhhh that needs to go over the openvpn tunnel to the end device 192.168.7.200:18990
I dont think i can put it any clearer than that.
So the 4G LTE router will need to know to send the reply traffic back out the OpenVPN tunnel instead of its default gateway. This is all handled there. Nothing pfSense A can do about it.
You might be able to use Outbound NAT to work around it. But that would involve accurately describing the problem first.
@derelict ta, i will have another play. Although i didnt make any changes in the 4G router last time i had it working, although last time it was an Asus router with 4G dongle in. This time its Teltonika 4G router, so things could well be different.