Portforwarding on WAN Interface via Site to Site IPsec
-
Hi all!
i am trying to forward traffic incoming on WAN Interface Port 4433 to a client behind my site-to-site IPsec network.
Setup
wan <-> 85.25.xx.xx pfsense 192.168.122.1 <--ipsec--> usg 192.168.2.1 <-> local network 192.168.2.0/24- pfSense is via public WAN interface connected to the WWW
- USG Firewall is public connected to the WWW
- pfSense and USG have runnnig IPSec
- Devices in 192.168.122.0/24 can ping devices in 192.168.2.0/24 and via versa
Goal
Expose 192.168.2.105:4433 via 85.25.xx.xx:4433 throw IPsecWhat I have done so far
Created a new Rule in Firewall -> NATInterface: WAN
Adress Family: IPv4
Protocoll: TCP
Destination: WAN
Dest. Port Range: Other 4433 to Other 4433
Redirect Target IP: Single Host -> 192.168.2.105
Redirect Target Port: 4433
NAT Reflection: defaultDebugging Steps
First of all I tried to Ping 192.168.2.105 via pfSense Diagnostic -> Ping.
Here is maybe the clue.
Interface Automatically: No Ping
Interface LAN: Ping is workingTraffic Capture on client device.
Solution
So it seems like my issue is maybe related to the host-itself traffic or routing?
First I tried to register a new gateway to setup a route, but I dont know which IP would be the next-hop. So that seems not to be the correct way?I am not quite sure what exactly the root issue is, i am facing to. Usually, as soon the issue itself is identified, it is kind solved ... ;)
I am looking forward for any kind of input, hint, push or help!
Spending tons of gray hair on this issue!Thanks in advance!
RB -
@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.
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.
-
@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.