IPSec/NAT: Have client on local LAN use use remote OPNSense's IP Address

Started by tuaris, June 06, 2024, 11:52:37 PM

Previous topic - Next topic
I know this is probably a question that has been asked an answered multiple times.  Problem is that my searches on this forum are not producing any results.  I think it's because I am probably not working it correctly.

I have 2 OPNSense boxes:

- Site A: IP of WAN: 1.2.3.4
- Site B: IP of WAN: 9.8.7.6

There is a site-to-site tunnel created between the two.  LAN clients can communicate with each other.  Good so far.

I would like to have all LAN clients in Site A that connect to a specific public IP address (or host name if possible), appear as if they are in Site B.

In other words, a LAN client in Site A opens the page http://showthisip.com and see's 9.8.7.6, but only for that page.  If I go to http://seethisip.com (assume for the moment for the purpose of this example that the two sites resolve to different IP's), I will see 1.2.3.4

Am I correct that if I follow the instructions on one of these paged, I will achieve the above?
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route.html
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-route.html

Which one should I follow?

I've run through the instructions and I can get hosts on each of the local networks to connect with each other.  I will admit, this is an interesting way of getting IPSec tunnels setup.

Problem is if I add a route to a public IP on Site A that points to the VTI on Site B, the packets seem to go nowhere.



traceroute -n 162.55.60.2
traceroute to 162.55.60.2 (162.55.60.2), 64 hops max, 40 byte packets
1  192.168.1.1  0.234 ms  0.168 ms  0.196 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
...


Probably has something to do with NAT, but I'm not sure how to fix it.

Maybe it's not NAT related sine it appears OPNsense is properly auto-generating those:



I added a firewall rule for the IPsec interface at Site B to allow anything through (for testing purposes).  That got me one step closer (it seems).



# traceroute -n 162.55.60.2
traceroute to 162.55.60.2 (162.55.60.2), 64 hops max, 40 byte packets
1  192.168.1.1  0.347 ms  0.272 ms  0.158 ms
2  10.192.168.8  151.799 ms  151.946 ms  151.913 ms
3  * * *
4  * * *
5  * * *
6  * *^C