How can I do NAT Reflection without enabling NAT Reflection.
-
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?