Destination NAT on VPN
I read this:
In particular this picture:
The first part is very clear: we have LAN1, we have to reach REMOTE with FAKE address.
But the latest, DNAT that does the contrary, seems a Virtual Server NAT setting.
Is it needed, if only LAN1 has to reach REMOTE but REMOTE does not need to reach LAN1?
Accepted Solution
-
Hi @valerio_vanni ,
Could it be that return traffic rule is implicit, and Inbound Destination NAT is only needed for something that starts from the other side
?Firewall handle traffic before send out is all based on the session initialed.
Once the initial traffic goes out, the SNAT session is created in session table.
And the return traffic matching the created session and firewall send to the original IP:PORT.
You can use CLI to show the session table: "debug system show conntrack | match "original ip"
DNAT is for the case, traffic is initial from the peer.
Once the initial traffic come in, the DNAT session is created in session table.
And the return traffic matching the created session and firewall send out with DNAT IP:PORT.
0
All Replies
-
-
So if LAN1 is a /24 network, and Fake is a /32, result is similar to "typical" LAN internet access (that goes to WAN snatted to WAN address), right?
And additional specific rules with specific port and specific LAN1 addresses
2 Fake subnet (/32) - specific LAN1 ip100 - protocol1 - service1 etc
3 Fake subnet (/32)- specific LAN1 ip101 - protocol2 - service2 etc
would result as virtual server rules that forward service1 to ip101, service2 to ip102 etc, right?
In that case, should these specific rules be upper in list (before the generic one)?
0 -
Some hour ago it didn't work. I had configured it without Destination NAT, a doubt came to my mind and so I asked.
Then I tried to add Destination NAT and it was still not working.
I did a phone call with manager of the other side of tunnel, and we found there was some issue on that side . As long as it was fixed, it began to work.
Then I tried to remove Destination NAT, and it continued to work.
In order to talk about something certain (and not before - after - between this and that) I describe how it is set up now:
*****
VPN tunnel (up)
local policy: Fake_Subnet/24
remote policy: Remote_Subnet/32
Outbound traffic - "Source NAT" is enabled,
Local: LAN1_Subnet/24
Remote: Remote_Subnet/32
SNAT: Fake_Subnet/32
Inbound traffic - Source NAT is disabled
Inbound traffic - Destination NAT is disabled and no rule is present
****
A policy route is active
incoming interface: lan1 - source address: LAN1_SUBNET - destination address: remote - specific service - next hop tunnel - tunnel: the correct one
****
As a test, I tried (from a LAN1 host) to reach a port (on Remote) with MS tcpquery, and I found it listening.
At the time of the test, if I go to (USG-Flex-200) diagnostic - routing traces and I enter destination host and port, in capture I find three entries:
- Real LAN IP → remote IP - The packet outgoing interface: doll
- Fake LAN IP → remote IP - The packet outgoing interface: doll
- Remote IP → Real LAN IP - The packet outgoing interface: lan1
Could it be that return traffic rule is implicit, and Inbound Destination NAT is only needed for something that starts from the other side?
0 -
Hi @valerio_vanni ,
Could it be that return traffic rule is implicit, and Inbound Destination NAT is only needed for something that starts from the other side
?Firewall handle traffic before send out is all based on the session initialed.
Once the initial traffic goes out, the SNAT session is created in session table.
And the return traffic matching the created session and firewall send to the original IP:PORT.
You can use CLI to show the session table: "debug system show conntrack | match "original ip"
DNAT is for the case, traffic is initial from the peer.
Once the initial traffic come in, the DNAT session is created in session table.
And the return traffic matching the created session and firewall send out with DNAT IP:PORT.
0
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 147 Nebula Ideas
- 96 Nebula Status and Incidents
- 5.7K Security
- 262 USG FLEX H Series
- 271 Security Ideas
- 1.4K Switch
- 74 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.4K Consumer Product
- 249 Service & License
- 387 News and Release
- 84 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.5K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 85 About Community
- 73 Security Highlight