Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 2352 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

XGS2100 RED Full NAT

Rolf Dobrig

Hello,
our customer has an XGS 2100 HA installation with currently two REDs. So far it's going very well. Now our customer has taken over three additional locations and would now like to connect these to the internal network with the XGS RED environment.

The problem, however, is that the respective IPv4 networks that exist at the three locations are already present in the internal network. A renumbering of the external networks (of the three locations) is not yet planned and the central servers are located in the internal networks.

I therefore set up a test lab and tried to create the configuration for this.

If different networks are used inside and outside, the configuration also works wonderfully with Full NAT. A ping from inside to outside works with a 1:1 address translation. When pinging from outside to inside, the 1:1 address translation doesn't work, but the ping comes via a randomly selected IP address and works.

Afterwards, as a further test, I set up a VM in an internal server network. I have enhanced the corresponding networkk in the NAT rule. Ping from the new server network inside to outside doesn't work.

I connect to the XGS and make some trouble shooting and I see, that on the reds1 Interface the first three icmp request goint well, but the it stopped.

SFVUNL_KV01_SFOS 19.5.3 MR-3-Build652# tcpdump -n -i reds1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on reds1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:44:17.018204 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP echo request, id 30, seq 1, length 64
14:44:17.086702 reds1, IN: IP 192.168.2.21 > 192.168.2.23: ICMP echo reply, id 30, seq 1, length 64
14:44:18.048642 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP echo request, id 30, seq 2, length 64
14:44:18.130251 reds1, IN: IP 192.168.2.21 > 192.168.2.23: ICMP echo reply, id 30, seq 2, length 64
14:44:19.072624 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP echo request, id 30, seq 3, length 64
14:44:19.141056 reds1, IN: IP 192.168.2.21 > 192.168.2.23: ICMP echo reply, id 30, seq 3, length 64
14:44:20.096498 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP echo request, id 30, seq 4, length 64
14:44:20.158114 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP host 192.168.2.23 unreachable, length 92
14:44:20.158326 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP host 192.168.2.23 unreachable, length 92
14:44:20.158355 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP host 192.168.2.23 unreachable, length 92
14:44:20.174173 reds1, IN: IP 192.168.2.21 > 192.168.2.23: ICMP echo reply, id 30, seq 4, length 64
14:44:21.120387 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP echo request, id 30, seq 5, length 64
14:44:21.180679 reds1, IN: IP 192.168.2.21 > 192.168.2.23: ICMP echo reply, id 30, seq 5, length 64
14:44:23.230009 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP host 192.168.2.23 unreachable, length 92
14:44:23.230163 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP host 192.168.2.23 unreachable, length 92

I do not understand why does the first three icmp requests got in icmp reply, but after that comes an icmp unreachable.

Please, can you give me an advice at this problem.

Many thanks and regards
Rolf



This thread was automatically locked due to age.
  • 0

    SFOS support DNAT 1:1 NAT, not 1:1 NAT for SNAT. Which means: If you ping from A to B, SFOS can translate the B to C, but the Source will be MASQ with a random IP (in terms of SNAT). You could also use SNAT MASQ (Interface IP). 

    Essentially you need two NATs: From A to B with 1:1 and from B to A with 1:1. 

    To be more specific: What SFOS does in a NAT Rule is a 1:1 DNAT only and doing the MASQ if needed. It does not create a FULL NAT 1:1 as a recursive rule. You need the other way around as well. 

    The missing Source NAT SNAT is not important for a working connection - Only for reporting or such things, it could be important. But the connection works fine with an MASQ. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hello Liuca,

    many thanks for your support. Tommorow morning I am back on this topic an I wil check your hints.

    Regards

    Rolf

  • 0 in reply to LuCar Toni

    Hello Lucar,

    yes, I understand what you mean with

    SFOS support DNAT 1:1 NAT, not 1:1 NAT for SNAT. Which means: If you ping from A to B, SFOS can translate the B to C, but the Source will be MASQ with a random IP (in terms of SNAT). You could also use SNAT MASQ (Interface IP)

    I see this also in my lab, but this is not the real problem.

    My Knockout problem is the outgoing connection from the internal network to the external network. The customer has internal and after taken over from this three new location external the same networks in use.

    If I made a ping from the internal test client is see the icmp request incoming on the PortA Interface from the XGS and also outgoing from the reds1 Interface. The outside client replies to the icmp request and I see this also on the reds1 interface. But then the XGS send out an icmp unreachable oacket to the outside client.

    FVUNL_KV01_SFOS 19.5.3 MR-3-Build652# tcpdump -n -i reds1 icmp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on reds1, link-type EN10MB (Ethernet), capture size 262144 bytes
    12:55:17.939367 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP echo request, id 16, seq 1, length 64
    12:55:18.007213 reds1, IN: IP 192.168.2.21 > 192.168.2.23: ICMP echo reply, id 16, seq 1, length 64
    12:55:21.086111 reds1, OUT: IP 192.168.2.23 > 192.168.2.21: ICMP host 192.168.2.23 unreachable, length 92
    ^C
    3 packets captured
    3 packets received by filter
    0 packets dropped by kernel
    SFVUNL_KV01_SFOS 19.5.3 MR-3-Build652#

    Currently I find no way around this problem and I almost assume that this behavior is normal.

    If it is so, the only way to solve the problem could be double nat.

    regards

    Rolf

Unfiltered HTML