- Tunnel Interface
- Proposals and VPN
- Routing
- Policies
Tunnel Interface and zone
As in ScreenOS I am using an unnumbered tunnel interface, in ScreenOS the tunnel interface will borrow the IP address of the interface it is bound to. In JUNOS this is slightly different, the IP address is borrowed from the security zone it is bound to. This does a raise a question for me as I have not assigned an IP to the Security zone so I am not sure what it is using, anyone?
root@host# set interfaces st0 unit 0 family inet
root@host# set security zones security-zone VPN_Zone
root@host# set security zones security-zone VPN_Zone interfaces st0.0
Additionally in order for incoming IKE connections to be accepted you need to enable IKE on the incoming interface zone, in our case this would be fe-0/0/0.0 which sits in the Untrust_Zone
root@host# set security zones security-zone Untrust_Zone host-inbound-traffic system-services ike
Proposals and VPN
For the purposes of this configuration I am using the SRX 'standard' proposal which is "esp-group2-3des-sha1” and “espgroup2-aes128-sha1”. These first statements basically define the IKE Policy and the Gateway
root@host# set security ike policy LAB_IKE_POL mode main
root@host# set security ike policy LAB_IKE_POL proposal-set standard
root@host# set security ike policy LAB_IKE_POL pre-shared-key ascii-text "Password123"
root@host# set security ike gateway LAB_GW_POL ike-policy LAB_IKE_POL
root@host# set security ike gateway LAB_GW_POL address 65.9.248.130
root@host# set security ike gateway LAB_GW_POL external-interface fe0/0/0.0
Again I am using the SRX 'standard' proposal for the IPSEC Policy
root@host# set security ipsec policy LAB_VPN_POL proposal-set standard
Finally we bind the Tunnel Interface, Gateway and IKE together to create the VPN
root@host# set security ipsec vpn LAB_VPN_01 bind-interface st0.0
root@host# set security ipsec vpn LAB_VPN_01 ike gateway LAB_GW_POL ipsec-policy LAB_VPN_POL
root@host# set security ipsec vpn LAB_VPN_01 ike ipsec-policy LAB_VPN_POL
Routing
I am using multiple VRs in my SRX configuration, if you come from a ScreenOS background then you work on the principle that the Tunnel Interface is bound to the VR that the outgoing (Untrust for example) interface is in. This is different in JUNOS and as you can see I have bound the Tunnel (st0.0) to the Trust-VR. JUNOS documentation (see earlier blog on VRs) has stated that a limitation at present, is that Tunnel Interfaces can only be bound to the inet.0 routing instance, as I have effectively created two new routing instances in Trust-VR.inet.0 and Untrust-VR.inet.0 it seems that the tunnel can be bound to another instance however that instance has to have the interface where the traffic over the VPN is destined, in our configuration this will be fe-0/0/1.0
root@host# set routing-instances Trust-VR routing-options static route 10.10.11.0/24 next-hop st0.0
root@host# set routing-instances Trust-VR interface st0.0
Policies
This is simply the configuration of the policies for the VPN
root@host# set security zones security-zone VPN_Zone address-book address LAB_LAN_10.10.11.0/24 10.10.11.0/24
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit match source-address LAB_LAN_172.16.201.0/24
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit match destination-address LAB_LAN_10.10.11.0/24
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit match application any
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit then permit
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit then log session-init
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit then log session-close
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit then count
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit match source-address LAB_LAN_10.10.11.0/24
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit match destination-address LAB_LAN_172.16.201.0/24
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit match application any
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit then permit
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit then log session-init
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit then log session-close
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit then count
Configure Tcp-mss to Eliminate Fragmentation of TCP Traffic Across Tunnel
root@host# set security flow tcp-mss ipsec-vpn mss 1350
Juniper note:
Tcp-mss is negotiated as part of the TCP 3-way handshake. It limits the maximum size of a TCP segment to better fit the maximum transmission unit (MTU) limits on a network. This is especially important for VPN traffic as the IPsec encapsulation overhead, along with the IP and frame overhead, can cause the resulting Encapsulating Security Payload (ESP) packet to exceed the MTU of the physical interface, thus causing fragmentation. Fragmentation increases bandwidth and device resources and is always best avoided. Note that the value of 1350 is a recommended starting point for most Ethernet-based networks with an MTU of 1500 or greater. This value may need to be altered if any device in the path has lower MTU, or if there is any added overhead such as Point-to-Point Protocol (PPP), Frame Relay, etc. As a general rule, you may need to experiment with different tcp-mss values to obtain optimal performance.
No comments:
Post a Comment