Source NAT through vpn tunnels

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

Let's say we have three sites:

Site A (USG Flex 50) - Policy based vpn - Site B (USG Flex 200) - Policy based vpn - site C (other device, managed by others)

Note: between A and B it's simple routing, hosts keep their IP.

Between B and C it's different: all B lan address reach C site SNATted (in B-C vpn policy) to a single fake address (FakeB). C site is a /32, and knows only that single fake address as remote policy.

Another note: C is only meant to be reached.

Between B-C things work.

Now there is a need: an host of A should reach C.

This would require:

-on A, policy route with source A client - destination site C - next hop tunnel A-B

-on B, policy route with source vpn tunnel - A client - destination site C - next hop tunnel B-C

This would be ok if all was simply routed. But A client must go to C SNATed to FakeB.

I did some test and it doesn't seem possible. Or perhaps I missed something.

-VPN policy C-B, in its SNAT section, already defines SNAT of RealB to FakeB. So, it cannot deal with an A-lan object.

-In policy routes (A-B and B-C), when you select a tunnel as next-hop, "SNAT-to" setting is not present.

Now I think I should convert vpn A-B to VTI: since VTI appears as "interface", it leaves "SNAT-to" available.

Is it the right way?

All Replies

  • zyman2008
    zyman2008 Posts: 222  Master Member
    25 Answers First Comment Friend Collector Seventh Anniversary
    edited December 20

    Hi @valerio_vanni,

    Since policy based VPN of Zyxel firewall only allow one SNAT rule for outbound(B to C).

    I think may be try another way,

    1.Create route-based VPN Connection rule for B - C, then you get a VTI interface to C.

    But you need using CLI to modify the local/remote policy from any to the address object B, C

    crypto map VPNConnectionName

    local-policy any → local-policy address-objectB

    remote-policy any → remote-policy address-objectC

    2.Create policy route rule for B to C, SNAT to fakeB.

    3.Create policy route rule for A to C, SNAT to fakeB.

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

    As I said, site C is out of control and that VPN is "untouchable" on that side.

    Or what you suggest in point 1 would make C side "happy" only setting with CLI local and remote policies? IP of VTI would play no role, right?

    Does VTI likes this change from CLI? Is it supported or there's some risk that some firmware upgrade reverts back these values?

    My idea would be of a VTI on A-B.

    So

    B-C vpn policy would keep on SNATting B Lan (like now)

    Policy rule on A firewall (from A lan to VTI) would SNAT A client to FakeB;

    At the next step, policy route on B firewall (from VTI to B-C tunnel) doesnt' need to SNAT because the source is already FakeB.

    But I like your idea, if it doesn't require changes on C.

    About mine, I'm worried about double wan. In VTI documentation I read that (in bold what I noticed):

    Restrictions for IPSec Virtual Tunnel Interface

    •IPv4 traffic only

    •IPSec tunnel mode only. A shared keyword must not be configured when using tunnel mode.

    •With a VTI VPN you do not add local or remote LANs to your VPN configuration.

    For a VTI VPN you should only have one local and one remote WAN.

    •A dynamic peer is not supported

    •The IPSec VTI is limited to IP unicast and multicast traffic only.

    A shared key must not be configured? Why?

    Only single WAN? A-B, now, has double (single on A, double on B). Should I, then, make 2 VPN gateways (A-Bwan1, A-Bwan2), 2 VPN connections and 2 VTI (and finally trunking the latest)?

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

    I decided to try your way.

    1.Create route-based VPN Connection rule for B - C, then you get a VTI interface to C.

    But you need using CLI to modify the local/remote policy from any to the address object B, C

    crypto map VPNConnectionName

    local-policy any → local-policy address-objectB

    remote-policy any → remote-policy address-objectC

    This works, vpn is up and vti too.

    2.Create policy route rule for B to C, SNAT to fakeB.

    Even this works: in routing traces I see three steps

    -real B LAN → C host - from vpn id 0 to id 0 - incoming interface x - outgoing VTI0

    -fake B LAN → C host - from vpn id 0 to id 0 - incoming interface x - outgoing VTI0

    -C host → real B LAN - from vpn id 5 to id 0 - incoming interface x - outgoing LAN1

    3.Create policy route rule for A to C, SNAT to fakeB.

    And this doesn't work. I've checked also policy control but it doesn't generate events, it seems a routing issue.

    On A firewall, I simply see

    -A host → C host - from vpn id 0 to id 2 - incoming interface x - outgoing doll

    But nothing comes back.

    On B firewall, traffic is received from A site, sent to C, received from C and finally not sent to A.

    Routing traces show

    -A host → C host - from vpn id 3 to id 0 - incoming interface x - outgoing VTI0

    -Fake B LAN → C host - from vpn id 3 to id 0 - incoming interface x - outgoing VTI0

    -C host → real A host - from vpn id 5 to id 0 - incoming interface x - outgoing WAN1

    Outgoing WAN1… why?

    I look at rule and I don't find anything wrong

    user: any - incoming: tunnel - A-B - source address: A host - destination address: C host - dscp: any - schedule: none - Service: selected (also tried "any", it doesn't change) - next hop: interface VTI0 - SNAT to fake B

  • PeterUK
    PeterUK Posts: 3,457  Guru Member
    100 Answers 2500 Comments Friend Collector Seventh Anniversary

    This is a lot to take in.

    If site A LAN is 192.168.11.0/24
    site B LAN is 192.168.22.0/24
    site C LAN is 192.168.33.0/24

    You have site B 192.168.22.0/24 SNAT site to site to single fake address 192.168.44.1 to get to site C

    and now you want site A to go to C as that fake address 192.168.44.1 through B.

    is that about right?


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

    Right.

    In initial setup, traffic flowed from A to B but then cannot go to C with SNAT.

    Zyman2008 suggestion made things better. Now it goes to C with SNAT, it comes back to B but then it runs away on B WAN1 interface instead of going towards tunnel A-B.

  • zyman2008
    zyman2008 Posts: 222  Master Member
    25 Answers First Comment Friend Collector Seventh Anniversary
    edited December 21

    Hi @valerio_vanni ,

    it goes to C with SNAT, it comes back to B but then it runs away on B WAN1 interface instead of going towards tunnel A-B.

    Does A and B using policy-based IPSec VPN ? what's the local/remote policy ?

    If the local/remote of rule A-B doesn't include subnet C.

    Then you need another policy route on B, to enforce the return traffic from C to A go into tunnel A-B.

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

    VPN policy A-B has only A and B LAN1 subnets as local-remote policy.

    Just to see if it helped, I had set policy route on B, but it didn't work.

    With source VTI0 - dest A-B tunnel, last step went to WAN1, with source B-C tunnel - dest A-B tunnel it went to doll (but nothing to site A).

    At that point, my suspect was that A-B tunnel rejected all what was outside its local-remote policy. Even if it was a return of something that had come out from it, and even with a policy.

    So I created another phase 2 on same phase 1 between A-B, let's call A2-B2 tunnel.

    On A, local-policy = A client - remote policy: C Host.

    On B, the opposite.

    Then, traffic began to flow.

    The last step of trace on B firewall, from

    -C host → real A host - from vpn id 5 to id 0 - incoming interface x - outgoing WAN1

    became

    -C host → real A host - from vpn id 5 to id 6 - incoming interface x - outgoing doll

    id 6 is the new tunnel, A2-B2

    Traffic didn't use same tunnel, it went from A to B in A-B tunnel (id 3) and came finally back in A2-B2 tunnel (id6).

    Then I changed policy route on A to use A2-B2 as next-hop, and on B to use A2-B2 as source. Just because I like more this way, that both directions use same tunnel :-)

    In both cases (same or different tunnel for opposite directions), I didn't need any "return" rule on B.

  • PeterUK
    PeterUK Posts: 3,457  Guru Member
    100 Answers 2500 Comments Friend Collector Seventh Anniversary

    so this is solved?

Security Highlight