Destination NAT on VPN

valerio_vanni
valerio_vanni Posts: 117  Ally Member
5 Answers First Comment Friend Collector Third Anniversary

I read this:

https://mysupport.zyxel.com/hc/en-us/articles/360003321659--ZyWALL-USG-How-to-configure-VPN-SNAT-on-Zyxel-gateways

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

  • zyman2008
    zyman2008 Posts: 223  Master Member
    25 Answers First Comment Friend Collector Seventh Anniversary
    Answer ✓

    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.

All Replies

  • Zyxel_Melen
    Zyxel_Melen Posts: 2,577  Zyxel Employee
    Zyxel Certified Network Engineer Level 1 - Switch Zyxel Certified Network Administrator - Switch Zyxel Certified Network Administrator - Nebula Zyxel Certified Sales Associate

    Hi @valerio_vanni,

    This is needed unless you only have UDP traffic.

    Zyxel Melen


  • valerio_vanni
    valerio_vanni Posts: 117  Ally Member
    5 Answers First Comment Friend Collector Third Anniversary
    edited December 18

    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)?

  • valerio_vanni
    valerio_vanni Posts: 117  Ally Member
    5 Answers First Comment Friend Collector Third Anniversary
    edited December 18

    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:

    1. Real LAN IP → remote IP - The packet outgoing interface: doll
    2. Fake LAN IP → remote IP - The packet outgoing interface: doll
    3. 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?

  • zyman2008
    zyman2008 Posts: 223  Master Member
    25 Answers First Comment Friend Collector Seventh Anniversary
    Answer ✓

    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.

Security Highlight