Portforwarding on WAN Interface via Site to Site IPsec
-
@viragomann said in Portforwarding on WAN Interface via Site to Site IPsec:
@operaiter said in Portforwarding on WAN Interface via Site to Site IPsec:
wan <-> 85.25.xx.xx pfsense 192.168.122.1 <--ipsec--> usg 192.168.2.1 <-> local network 192.168.2.0/24
I'll call them site A and B.
I guess, you don't want to direct the whole upstream traffic from B to A.
I would prefere to keep our uplink locally.
If not, it's on the USG to properly route response packets from the destination server back to A.
But I'm in doubt, that it's capable of doing this, when the destination IP is a public one. So you're only option might be to NAT the forwarded traffic at A to a local IP, one of the local subnet in the phase 2.
You have a VTI setup in mind don’t you?
As I am doing inbound NAT I assumed it will be translated to the fw local LAN IP anyway. Do you think this is possible with tunnel mode in place?
Not sure, but seemed to me USG is not doing tunnel mode on ipsec.
Did I understand you correctly? We have an asymmetric routing?
WAN -> pfsense -> IPsec -> USG -> client -> USG -> WAN ?
Means Traffic capturing should be captured on client Interface from source of my sita A public IP? -
@operaiter said in Portforwarding on WAN Interface via Site to Site IPsec:
You have a VTI setup in mind don’t you?
No. If I recall correctly, that doesn't either work with a VTI tunnel. But I'm not experienced with it.
And I don't know, if it's supported by the USG.As I am doing inbound NAT I assumed it will be translated to the fw local LAN IP anyway.
NAT port forwarding only translates the destination address and possibly the port, but not the source IP (masquerading).
Did I understand you correctly? We have an asymmetric routing?
WAN -> pfsense -> IPsec -> USG -> client -> USG -> WAN ?Yes, I suspect so.
Means Traffic capturing should be captured on client Interface from source of my sita A public IP?
Don't understand.
You can run a capture on the IPSec at A. I'd suspect, you will see the forwarded packets, but no responses coming back.As mentioned, you can nat the traffic to the LAN IP or any other you assign to pfSense at A, so that responses come back.
-
NAT port forwarding only translates the destination address and possibly the port, but not the source IP (masquerading).
Maybe this is root of the issue. But can’t find this topic in docs. Do you know by any chance where I can configure the masq settings?
-
@operaiter
pfSense does masquerading only on outgoing traffic. But this doesn't work for IPSec, here you have to do it in IPSec phase 2.So I assume, you have configured a phase 2 with
local network: 192.168.122.0/24
remote network:192.168.2.0/24
and 192.168.122.1 is the LAN IP at A.Copy this p2 and edit it:
local network: 0.0.0.0/0
NAT/BINAT translation: Address > 192.168.122.1
remote network: Address > 192.168.2.105 -
@viragomann said in Portforwarding on WAN Interface via Site to Site IPsec:
@operaiter
pfSense does masquerading only on outgoing traffic. But this doesn't work for IPSec, here you have to do it in IPSec phase 2.wow! This would the last space I assumed this setting! Thank you so much!
I reconfigured it, restartet the IPsec but the device is not accessible.Unfortionally I cant trouble shoot from remote. I will traffic capture next week and check what is going on.
-
hmm...
should not I capture traffic on the pfSense IPsec interface?According to my firewall logs the incoming traffic on the WAN interface is passed.
-
sorry...
I did setup the same rules for a second device i can access remote.I can access from a device in Site A the Device in Site B.
I do see traffic on all hops as expected.If I try from firewall itself or public via WAN I cant capture anything.
Means we can now locate the issue to the pfSense config. -
@operaiter said in Portforwarding on WAN Interface via Site to Site IPsec:
If I try from firewall itself or public via WAN I cant capture anything.
On the IPSec interface?
As I said before, I'd expect to see at least request packets. If there are none check the port forwarding rule.
Did you pfSense let an associated firewall rule or just state "pass" to allow the traffic? -
@viragomann said in Portforwarding on WAN Interface via Site to Site IPsec:
@operaiter said in Portforwarding on WAN Interface via Site to Site IPsec:
If I try from firewall itself or public via WAN I cant capture anything.
On the IPSec interface?
As I said before, I'd expect to see at least request packets. If there are none check the port forwarding rule.I did just double checked the rule. Furthermore I did setup a new rule with different traget and port. Still cant see outgoing traffic on pfSense interface.
Did you pfSense let an associated firewall rule or just state "pass" to allow the traffic?
I am using a double wan setup. That is why i followed the suggestion to let pfSenses create the associated rule. Is this what you would recommend?
Sideinfo:
Now I fixed my issue by using a technically different approach. Instead of exposing the device via port forwarding / natting, I did setup a reverse proxy via nginx. The reverse proxy sits in the LAN of Site A and is now able to talk to the Device in Site B LAN.But I am still wondering and trying to follow the direct solution. It is not the first time I needed a port forward.
-
@operaiter said in Portforwarding on WAN Interface via Site to Site IPsec:
I did just double checked the rule. Furthermore I did setup a new rule with different traget and port. Still cant see outgoing traffic on pfSense interface.
The only reasons for this apart from NAT and filter rules, I can think of, is that the tunnel is not working properly.
Possibly the additional phase 2 is not correct or not accepted. Some IPSec implementations may reject this multiple phase 2 for the same or overlapping subnets.
You can check out the log for hints due this.