Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 1 subscriber
  • Views 5159 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

Verify SNAT Configuration

troy.murray
I have a site-to-site VPN connection setup with an external client.  Both phrases complete successfully and the connection is up.  Now I need to have an internal IP address source masqueraded using the external IP address of my device.  I setup a SNAT rule for this, and believe I have it configured correctly:
Traffic source: My systems internal IP address
Traffic service: FTP
Traffic destination: Their internal systems IP address
NAT Mode: SNAT
Source: External IP Address of my ASG
Source Service: FTP

I also created a packet filter rule that allows traffic from my systems internal IP address to their internal systems IP address using the service FTP.  Everything is saved and loaded.

When I try to FTP to their systems internal IP address, nothing shows up in their logs.  If I disable my SNAT, then it shows traffic in their logs but with my systems internal IP address, not my ASG external address.

Is there a way I can confirm the SNAT rule is working correctly and re-written the source of the packet to be the ASG external address?


This thread was automatically locked due to age.
Parents
  • 0
    Ethans, and also Troys problem, is solvable.  As Ethans problem is more specific I will explain how to solve this probem then the problem of Troy should be clear, too.

    Ethan wants to build a VPN tunnel between two networks with each has the same IP range. Even if the tunnel came up (can be it would come up, have never tested), of course no routing could happen between the networks.

    So here´s the trick:

    The "real" network on both sides is 192.168.0.0/24
    Assume 10.1.1.0/24 and 10.2.2.0/24 are two networks which do not exist on any of the two sides. I will call them the "virtual" networks. Net 10.1.1.0 will be assigned to loc1, net 10.2.2.0 to loc2
    The VPN tunnel definitions ("local" and "remote" networks) on both sides have to contain ONLY these two virtual networks - no 192.168.0-Network may be contained on both sides! This will lead to the vpn tunnel comes up without any problems.

    Now also the routing is just clear: if someone from location1 (the "client") wants to  initiate a connection to location2 (a "server"), there must be
    1) an SNAT rule in loc1
    2) a DNAT rule in loc2


    Example: 
    Client 192.168.0.4 in loc1 wants to make a connection to server 192.168.0.5 in loc2
    1) loc1- SNAT rule: src:192.168.0.4 dst:10.2.2.0/24  new src: 10.1.1.4 (for example)
    2) loc2-DNAT-rule: src: 10.1.1.4 dst:10.2.2.5  new dst:192.168.2.5

    So, the "client" has to contact the "server" with the "virtual-server-ip" 10.2.2.5. The packet goes from client to ASG1, which will SNAT the clients IP (192.168.0.4) to the "virtual-client-ip" 10.1.1.4  and - as this packet matches now the tunnel definition - send it via the VPN to the remote side. The gateway there (hopefully also an ASG...let´s call it asg2) will DNAT the packet to the real servers ip 192.168.0.5.
    The reverse packet will be natted vice versa.

    Of course, you won´t need a separate SNAT rule for every client in loc1 - if the admin (or the server) in loc2 doesn´t have to have a separate src ip of any client connection. then one SNAT rule for ALL clients would be sufficient.
    However, for every separate SERVER in loc2, the asg2 in loc2 wil need a separate DNAT rule. This is one of thevery seldom cases where a "NAT-range" feature would be nie in ASG (instead of creating 100 NAT rules for 100 servers, use 1 rule for range 1 to 100 or so).

    This setup  sounds complex but if you only have some few servers on each side which have to be contacted from the other side the setup is just some minutes. It´s proofen in many customer installations.
Reply
  • 0
    Ethans, and also Troys problem, is solvable.  As Ethans problem is more specific I will explain how to solve this probem then the problem of Troy should be clear, too.

    Ethan wants to build a VPN tunnel between two networks with each has the same IP range. Even if the tunnel came up (can be it would come up, have never tested), of course no routing could happen between the networks.

    So here´s the trick:

    The "real" network on both sides is 192.168.0.0/24
    Assume 10.1.1.0/24 and 10.2.2.0/24 are two networks which do not exist on any of the two sides. I will call them the "virtual" networks. Net 10.1.1.0 will be assigned to loc1, net 10.2.2.0 to loc2
    The VPN tunnel definitions ("local" and "remote" networks) on both sides have to contain ONLY these two virtual networks - no 192.168.0-Network may be contained on both sides! This will lead to the vpn tunnel comes up without any problems.

    Now also the routing is just clear: if someone from location1 (the "client") wants to  initiate a connection to location2 (a "server"), there must be
    1) an SNAT rule in loc1
    2) a DNAT rule in loc2


    Example: 
    Client 192.168.0.4 in loc1 wants to make a connection to server 192.168.0.5 in loc2
    1) loc1- SNAT rule: src:192.168.0.4 dst:10.2.2.0/24  new src: 10.1.1.4 (for example)
    2) loc2-DNAT-rule: src: 10.1.1.4 dst:10.2.2.5  new dst:192.168.2.5

    So, the "client" has to contact the "server" with the "virtual-server-ip" 10.2.2.5. The packet goes from client to ASG1, which will SNAT the clients IP (192.168.0.4) to the "virtual-client-ip" 10.1.1.4  and - as this packet matches now the tunnel definition - send it via the VPN to the remote side. The gateway there (hopefully also an ASG...let´s call it asg2) will DNAT the packet to the real servers ip 192.168.0.5.
    The reverse packet will be natted vice versa.

    Of course, you won´t need a separate SNAT rule for every client in loc1 - if the admin (or the server) in loc2 doesn´t have to have a separate src ip of any client connection. then one SNAT rule for ALL clients would be sufficient.
    However, for every separate SERVER in loc2, the asg2 in loc2 wil need a separate DNAT rule. This is one of thevery seldom cases where a "NAT-range" feature would be nie in ASG (instead of creating 100 NAT rules for 100 servers, use 1 rule for range 1 to 100 or so).

    This setup  sounds complex but if you only have some few servers on each side which have to be contacted from the other side the setup is just some minutes. It´s proofen in many customer installations.
Children
No Data