1:1 NAT Over OpenVPN Site2Site?
p3pp0 last edited by
i have two pfsense's running, which are connected via OpenVPN Site2Site. Clients on each Site can ping clients on the other side, so i guess my VPN is working fine. I have to move a server from Site A to site B.
I could move the Server but there would be a outage because i had to change the dns record from old-public-ip to new-public ip, which is not acceptable in my case.
My idea was to move the server in the night and to simply map the 1:1 nat to the moved server in the new lan at site B over the tunnel. If everything is working fine, i can change the dns record so that my customers can connect to my service anytime - no matter if their dns is already updated or not.
Everything is working fine, except when i change the 1:1 nat on SITE A to the server in the lan of SITE B… my browser get's a timeout.
Can anybody help me? Is mapping a 1:1 NAT over a tunnel generally possible?
OPT1: Public IP of Webserver
IP of Client (Webserver): 192.168.99.60
1:1-NAT FROM OPT1 to 192.168.99.60
OPT1: NEW Public IP of Webserver
IP of Client (Webserver): 192.168.199.104
pan_2 last edited by
Of course it times out - your request are finely routed to Site B, where they return to original requester by shorted path they know - through WAN of Site B router.
And requester just discards them, because it waits for them from Site A OPT1 address.
You should create Advanced NAT rule, refer to https://forum.pfsense.org/index.php?topic=132702.msg731475#msg731475
You need to assign an interface to the OpenVPN instance at Site B and make sure the rules passing traffic into that OpenVPN DO NOT match anything on the OpenVPN tab but do match on the assigned interface tab. That will flag the states with reply-to so reply traffic will be sent back through OpenVPN instead of according to the routing table.
Or just shorten the TTL on the A record in DNS to something like 5 minutes a while ahead of your move (how long depends on what your default TTL is), shut off the server, change the DNS, move the server, and by the time you get there the new address will have propagated everywhere.
Then just set the TTL back to something reasonable and you're done.