I am confused and have a question regarding site-to-site IPsec configuration.
Previously when creating site-to-site tunnels in New IPsec Policy section Src. Address and Dst. Address were both set up as internal subnets that will communicate with each other.
However I have a new requirement to set our Src. Address to our External IP address due to network limitations in the other site. I have created a tunnel (Our external_ip ↔ 2nd_site_internal_ip), connection is established.
Additionally I created NAT rule where chain: srcnat, src. address: external_ip, dst. address: internal_net_2nd_site
However I can’t ping second site, as I believe I am missing something in firewall.
Post the export of the current configuration. A NAT rule may be missing or be in wrong position, or it may be something completely else.
As for why the peer asks for that, there’s nothing strange about such a requirement - the private subnets of different peers may overlap, so using the peer’s public IP is the only way for them to make sure that they will deliver the response packets to the proper destination. But this approach fails if two peers connect from behind the same public IP address.
add action=accept chain=srcnat comment=“2nd Site IPSec”
dst-address=x.x.x.0/24 src-address=y.y.y.y to-addresses=
x.x.x.0/24
Where x.x.x.0/24 is other site internal subnet and y.y.y.y is our external IP.
Rule is 4th on the list (first 3 are for existing tunnels). Let me know if any additional information is needed. I believe there should be an additional Nat rule, but can’t figure..
Posting a single rule is useless as order of rules matters, and other parts of configuration may affect he behaviour too. See my automatic signature regarding anonymisation of the export.
The rule you’ve added does something else than what your OP suggests.
Usually, a generic src-nat or masquerade rule affects all traffic routed via WAN, and you have to add exceptions (by means of accept rules) from this generic treatment for traffic you tunnel from some local subnet(s) to some remote subnet(s) using IPsec.
But in your case, it’s the reverse - you need that the source address of the packets that establish connections from your LAN subnet(s) to 172.xx.xx.0/24 in the other company’s network are src-nated to the public IP of your router, so that the policy OUR_EXT_IP ↔ 172.xx.xx.0/24 could “see” them.
So if there is no “normal” route to 172.xx.xx.0/24, the default route is used, and then the usual masquerade rules might do that job; if there is, or if the masquerade rules are too selective, you need to replace your rule by src-address=source.lan.sub.net dst-address=172.xx.xx.0/24 action=masquerade
That’s why I’ve asked for a complete configuration, not just for the part you assume to be related. I can’t even say whether your policy is in accord with the description of the requirement in the OP.
One or the other will do - if you look at counters, only the first one counts, the other one never matches a packet. If the public IP is static, it is better to use src-nat as masquerade has some side effects, it removes existing connections if the address to which they are masqueraded is lost for watever reason. This is necessary for it to work properly where the public IP is assigned dynamically, but it brings unnecessary problems when the address is static.
What exactly does that mean, or, using other words, how do you know they do? The maximum you can see at your end is that if you start pinging something in their 172…, your router sends ESP packets to their public IP at the same intervals you use for the pings, and if you stop pinging, the ESP traffic stops as well (if it doesn’t, something in your LAN is trying to connect there, which is still an indication that the src-nat rule and the IPsec policy work properly).
You should not need a filter rule if your firewall is based on the default one, but as you still haven’t understood that to get a useful answer, you must provide a useful input (the complete export of the configuration, except sensitive info), it will take much longer than necessary to get so the silution. And I may lose my patience somewhere in that process.