Forum Discussion

vMitu_122667's avatar
vMitu_122667
Icon for Nimbostratus rankNimbostratus
Jan 23, 2013

Balancing juniper SRX dynamic-vpn

Hello.

 

Hope you have an idea how to make this work (how i got to this stage of performing such configuration is a long story, beyond the scope of this forum).

 

The scenario is the following: a F5 device must balance the Remote VPN sessions terminated in 2 different SRX device. the technology name in Juniper context is called dynamic-vpn, having the SRX outside interface as VPN gateway and JunosPulse as VPN client installed on the user workstation.

 

The connection process of junosPulse client is the following (detailed in the bottom of this thread):

 

1st, the junosPulse opens a tls connection (443) with the VPN gateway; in this tls session the junosPulse is injected with ipsec parameter details from SRX

 

2nd after this initial exchange the Junos Client initiates a IKE negociation, 1st packet of aggressive mode with upd/500

 

3rd, At the 3rd packet of aggressive mode both parties (junosClient and SRX) determine that the SRX is behind a NAT (for junosPulse, the IP address of VPN gw is the F5 virtual address and in the internal side of the F5 - load balancing pool - a snat operation is performed using the internal IP of the F5 - in the same subnet with the VPN gw IP). Because the VPN parties determine that Nat traversal must be used, the 3rd packet of aggressive mode and subsequent isakmp negociation (mode configuration and phase2-QuickMode) use udp/4500

 

4th, After IKE negotiation (tunnel up), the ESP packets are exhanged between JunosPulse and SRX, using IP Protocol ID 50.

 

i have the following ISSUE: because there are 2 SRX load-balanced in this scenario, i must make sure that: if the initial tcp/443 communication is balanced to a SRX device, the subsequent communications (2nd, 3rd and 4th packet exchange in the connection process) are balanced to the same SRX device otherwise the connection will be dropped.

 

I have no parameters between those 4 steps of connection process that can be parsed in order to create persistent connections (the solution i thought) except sourceIP of the the packets (that is the ip address of the JunosPulse Client) but this is very tricky because there are multiple branches of the organization and is very likely to have junosPulse clients behind a sNATting device.

 

Any ideas?

 

 

 

 

 

Here is the connection flow description with some other details i might skipped in the initial connection process:

 

Here is the packet flow:

 

  • Initial communication: F5 must balance port 443 because JunosPulse VPN Client and SRX650 open a TLS communication channel before any IPSec (IKE) packet is sent.
  • Assume that the tcp/443 connection was balanced by F5 device to VPN Gw number 2.
  • After this tcp/443 hand-shake the JunosClient initiates the IKE session on port upd/500. It must be found a method to ensure that this new “session” is balanced to the same VPN Gw number 2.
  • in the F5device, the original source IP is translated in the IP of the F5’s internal interface, so, both peers will realize that NAT-Tranversal must be used:
  • If first 2 IKE packets of Aggressive mode are on port udp/500, after NAT-Traversal detection, further IKE negotiation (3rd packet of Aggressive mode, transaction – mode cfg packets and quick mode) wil have the udp/4500 port.
  • It must be found a way to map previous udp/500 negotiation to the same VPN Gw number 2 on port upd/4500.
  • After IKE negociation takes place, the ESP protocol is used to protect data in transit. The ESP does not use layer 4 port numbers but IP Protocol ID 50. It must be found a way to map the previous negotiation on port udp/4500 with the new traffic session of IP Protocol ID 50.

 

 

Thank you for your suggestions.

 

 

 

 

 

 

3 Replies

  • No.

     

     

    they may be behind a Nat device so it is very likely to have multiple client workstations presented as a single IP to the outside world.

     

     

    Thank you

     

  • Ah, that's a shame. I can't really think of anything else which will uniquely identify each client and thus be used to persist the different connections. Can you?