How can I do NAT Reflection without enabling NAT Reflection.
-
I have a some vlans and the "WAN" interface. The "WAN" interface actually plugs into the ISP's Router/Modem.
So I have
VLAN10 -> 192.168.1.1/24
VLAN20 -> 192.168.2.1/24
WAN -> 192.168.254.2/24I have a server (ServerA) running on 192.168.1.50 with an open port of 3344
I have a NAT rule forwarding from WAN:4433 -> ServerA:3344I wanted to access ServerA on VLAN10 from ClientA (192.168.2.111) on VLAN20
so i went 192.168.254.2:4433 thinking it would forward the request from ClientA to ServerB.This did not happen and it is probably due to this.
Why can't I access forwarded ports on my WAN IP from my LAN/OPTx networks? By default, pfSense does not allow LAN/OPTx connected PCs to reach forwarded ports on the WAN interface. This is a technical limitation of how the underlying PF functions, it cannot "reflect" in and out the same Interface; it only works when passing "through" the router.Ok says me no harm no foul.
So I set up a third VLAN 30 -> 192.168.3.1/24
I do a NAT rule of VLAN30_Address:4433 -> ServerA:3344, thinking this surely should work as VLAN30_Address is not the WAN interface.I go 192.168.3.1:4433 …
But no cigar. Does not work either.
My question is, is there a reason why that should not work? Or am I doing it wrong?
If so how do I do it right. The simpler the better.In a nutshell what I am trying to do here is access ServerA on an IP address other than it's own real IP address.
Thanks! :)
-
Here is how I see it…
NAT reflection works for TCP, so if you have a WAN port forwarded to some machine on some subnet, then you can do that by accessing the public IP and port.
If its UDP you are playing with, it won't work same way.
From 1 machine on some subnet behind pfsense to another machine on some subnet behind pfsense using UDP, you can use the machine's real IP (not the WAN IP) or you can use DNS that resolves to the machine you are trying to reach.
If there are other things you can do, I'm not aware of those.
-
…. you can use the machine's real IP (not the WAN IP) ...
This is what I am trying not to do. I just would like to access the machine from an IP other than it's real IP. Yeah I am using udp to this server too.
-
You can use DNS for that if for some reason you don't like using the machine's IP directly.
As for typing in one IP and having the packets magically go to another IP, that sounds like a routing trick that I've never needed.
-
You can use DNS for that if for some reason you don't like using the machine's IP directly.
As for typing in one IP and having the packets magically go to another IP, that sounds like a routing trick that I've never needed.
DNS would resolve back to the real IP. What I wanted was a totally different IP like the IP of the WAN interface or the IP of a VLAN interface would have sufficed. But it looks like you cannot go from an internal lan to another internal lan and have that interal lan nat you to a third internal lan. Which I thought would have worked as pfsense docs says explicitly that this would not work only for the WAN interface. By the omission of not say it would not work for the other interfaces as well I assumed it would have until I had tried it. It would have been perfect.
-
OK - Sorry its not doing what you want.
Why would you want to do this? I'm dying to know. -
OK - Sorry its not doing what you want.
Why would you want to do this? I'm dying to know.I am trying to get openvpn to work from local vlans.
It works only if i connect from a remote area via the public Internet address.Why does it do this? It's because of a routing rule placed by openvpn.
For example….
From the information below (APPENDIX A) we see openvpn places a routing rule ofxx.xx.xx.xxx 192.168.3.1 255.255.255.255 UGH 0 0 0 wlan0in the client. Therefore I can safely ping 192.168.1.50 and down thru the tunnel it goes safely to everything on the 192.168.1.0/24 range.
APPENDIX A
FROM A REMOTE SUBNET ==================================================================== OPENVPN @ xx.xx.xx.xxx (PUBLIC IP) & 192.168.1.50 (LOCAL IP) OPENVPN GW @ 192.168.1.1 PFSENSE @ 192.168.1.1 CLIENT @ 192.168.3.107 on remote network CLIENT GW @ 192.168.3.1 on remote network Kernel IP routing table ----------------------------------------------------------------------------------- Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 128.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.3.1 0.0.0.0 UG 100 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 xx.xx.xx.xxx 192.168.3.1 255.255.255.255 UGH 0 0 0 wlan0 128.0.0.0 192.168.1.1 128.0.0.0 UG 0 0 0 tap0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0NOW…
when I connect from a VLAN locally i.e. this vlan does not need to pass thru a public address to get to the openvpn server. See the information is as below in APPENDIX B.Now look at the route entry
192.168.1.50 192.168.2.1 255.255.255.255 UGH 0 0 0 wlan0See that … that is causing a problem. It's sending communications to the openvpn sever at 192.168.1.50 not down the tunnel but outside of the tunnel and via the real network interface of the client. This is causing breakage where I cannot ping the openvpn server neither can the openvpn server ping the client neither can clients connected via openvpn ping each other. a connected client though can still ping regular clients on the 192.168.1.0/24 network. But any thing connected via the openvpn server and the server communications is broken.
This can be "easily" fixed If somehow I could have set up a vlan interface which only purpose was to forward a connection to the openvpn server. For instance if this vlan interface was 192.168.9.01/24 then openvpn would have inserted a routing rule of
192.168.9.1 192.168.2.1 255.255.255.255 UGH 0 0 0 wlan0This way, now I can safely ping 192.168.1.50 and expect it to whizz down the tunnel and everything would be good.
APPENDIX B
FROM A LOCAL SUBNET (VLAN) ==================================================================== OPENVPN @ 192.168.1.50 OPENVPN GW @ 192.168.1.1 PFSENSE @ 192.168.1.1 CLIENT @ 192.168.2.111 on local vlan CLIENT GW @ 192.168.2.1 on local vlan Kernel IP routing table ----------------------------------------------------------------------------------- Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 128.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.2.1 0.0.0.0 UG 100 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.1.50 192.168.2.1 255.255.255.255 UGH 0 0 0 wlan0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 128.0.0.0 192.168.1.1 128.0.0.0 UG 0 0 0 tap0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0Was that as clear as mud? :D
-
Ahhhhhh. Try this. Make yourself an openvpn server instance that uses TCP instead of UDP.
Its easy. Do everything as usual and click TCP in the openvpn server config.
See if that fixes you up. Also, tell it to route all traffic through VPN. -
Ahhhhhh. Try this. Make yourself an openvpn server instance that uses TCP instead of UDP.
Its easy. Do everything as usual and click TCP in the openvpn server config.
See if that fixes you up. Also, tell it to route all traffic through VPN.Following what you said here is what I did.
I set up a vlan70 and called it LAN_OPENVLAN 192.168.9.1/24
set the nat rule to foward any comms from 192.168.9.1:port to 192.168.1.1:port
Set the vpn instance to tcp, but still had to go into the nat rule for this and enable nat reflection. I guess that is the only way to do it?
I had to do the extact two things I did'nt want to do lol. Using tcp for openvpn and enabling nat reflection because I don't understand it quite well and was unnerved at all the scary language of what could go wrong when you enable this thing. I have only enabled it though on LAN_OPENVLAN. So I suppose it would not mess things up too much?If that is the case I will run three instances of openvpn. One for real remote clients using udp and one for local vlans using tcp.
-
Your final solution sounds reasonable.
-
-
Anytime… Although, I still don't know why you would want to do this?
-
You don't need NAT reflection at all. Client A can directly access Server A by its private IP address. It's plain LAN routing. You just need a firewall rule on VLAN20 that allows traffic to VLAN10.
You should use split DNS so that Server A's domain name resolves to its private IP for VLAN10 and VLAN20 clients, and to the WAN IP for external clients.
-
Yeah - He knows that, but for unfathomable reason he doesn't want to do that. Its strange but true. He is well aware he could use the private IPs. He just doesn't want to…
Yeah - I know... right?