IPSec DNAT not working
-
@Matt_Sharpe
Check your tunnel settings. Both local network or BINAT network must not overlap the remote network. -
@viragomann The VTI tunnel is set with a random/unique IP subnet we used for the VTI routing on both sides:
This doesn't overlap with any of the local/remote/isolated ranges?
-
@Matt_Sharpe
What's with the other tunnel? -
@viragomann The Azure tunnel?
-
@Matt_Sharpe
No, the one doing NAT.
But obviously you've deleted it already. So do you still see these log entries? -
@viragomann the other tunnel has been removed, as it impacts the live IPsec when enabled. If we tweak it to include the ranges in this forum post:
172.16.100.1 > IPsec tunnel > 172.16.200.253 (NATs to) 172.16.210.253
-
@Matt_Sharpe
This looks well for what you try to achieve.And I cannot find a hint for the disconnection of the other tunnel in the log.
But maybe there is an issue if you route the remote subnet over the VTI and also state it in the policy-based tunnel as remote network. -
@viragomann is there any other way we can achieve this? With native NAT rather than a profile on the IPSEC?
-
@Matt_Sharpe
I reread your intention. If your only aim is to access 172.16.210.253 from the remote site via RDP, it should also work with a simple NAT rule. You can add the rule to IPSec on pfSense like this:
interface: IPSec
source: may be limited to the remote network
destination: 172.16.200.253
redirect target: 172.16.210.253You can also limit it to RDP by stating
protocol: TCP/UDP
dest. and target port: RDPIt should also be possible to add this rule to the VTI IPSec interface instead.
If packets are coming in on IPSec interfaces addressed to the destination IP pfSense will redirect them to the target. The source IP in response packets will be translated back to the origin destination address due to the state table entry.
However, access in the other direction would not work this way, even not with NAT 1:1 or outbound NAT."Any" for interface as you mentioned above is not available in pfSense, however, you can create interface groups and apply rules to them. So the rules will be applied to all member interfaces of the group.
-
@viragomann I'm pretty sure I've already tried this as it's the most obvious solution:
How do we create interface groups?
-
@Matt_Sharpe found a deny in the logs from target NAT to source range IP. (Changed to our masked IPs in this forum post)
I do not have ANY deny rules set in IPsec interface, so why is it blocked??
-
@viragomann also TCP:SA packets blocked by same rule.
We have TCP IPv4 allowed in both directions, so why would it be blocked...
-
@Matt_Sharpe
Obviously pfSense has no proper state for the response. Search for it in Diagnostic > States.Is the RDP server on a remote site or is local?
How do we create interface groups?
Interfaces > Interface GroupsI assume, you won't use a group rule for this case?
-
@viragomann The RDP server (the target of the NAT rule) is in the same site as the PFsense we're applying it on.
No, not used for this case. Just curious for future use.
-
@Matt_Sharpe said in IPSec DNAT not working:
The RDP server (the target of the NAT rule) is in the same site as the PFsense we're applying it on.
Then I'm wondering, why a respond packet from the RDP server is shown up as entering IPSec.
So I'm out of ideas, what could be the reason for this blocks.
But you can probably circumvent it with a sloppy state rule (I don't like this):
action: pass
interface: IPSec
source: RDP server
source port RDP
destination: remote network
destination port: any
open the Advanced Options
at State type select SloppyI don't like it, but it should work.
-
@viragomann is that a NAT or FW rule?
-
@Matt_Sharpe
A firewall rule. A NAT rule ever needs a target... -
@viragomann I have created an isolated lab for this. Slightly different ranges.
Source site = 172.16.43.0/24
Target site = 172.16.200.0/24
Isolated network on target side = 172.16.210.0/24IPSEC Interface
FW rules any/any on IPV4.
Also enabled sloppy mode.
No joy.
I was tinkering with Outbound NAT rules for the interfaces to be able to route between each other which led to different results on a picture capture. Not sure if any specific outbound NAT would be required here:
