Categories
blog howto network

VPN tunnel between Netscreen and Cisco

Recently I had some troubles setting up a VPN between a Netscreen and a Cisco device from the remote party.

We had agreed upon a Preshared Key and 3DES/SHA1 encryption/hash algorithms using main mode and DH group 2. The Cisco side had added group 2 to their isamkp setting but they could not add the same group command to the transform command so my Phase2 had NOPFS set while my Phase1 was DH group 2.

The tunnel still did not come up, debugging was not useful as it was the Netscreen that initiated the tunnel every time and the log just showed an answer from the Cisco with “no proposal chosen”. After looking into their config and a hint on the internet, I configured the proxyID on the tunnel with local address = my WAN IP and remote address = their WAN IP. And that did the trick, tunnel was up.

Categories
blog network

FORTIGATE : Static routes must have lower distance then default GW

Had this problem on a Fortigate 60B & 60C. Static routes did not work as expected.
The static route did not work until the distance was set to 1 which is lower than the 0.0.0.0 default route who has distance 10. Maybe this is not a bug, but intended behaviour. On Netscreen the 0.0.0.0 default route is always the last to be applied and all other static routes go first.

Categories
blog howto network

Netscreen policy based routing cross virtual router

EDIT: Also read the comments, before implementing.

For a customer at work i was implementing PBR on his Netscreen NS25. Normally you have just 1 virtual router called trust-vr, which contains your trust and untrust interfaces. Inside this trust-vr you then have a routing table with a 0.0.0.0/0 route towards your ISP gateway. My customer had a second ISP connection in place to offload some of the traffic trough this connection. I connected the 2nd ISP to an unused interface and placed it in the “trust-vr” virtual router.
Problem: My new interface was not static, but PPoE (same like DHCP) and thus get it’s IP address automatically. However also the gateway is automatically received and set in the virtual router. Unfortunately automatically received gateway is set as connected type with a higher priority then any statically set default gateway. This means i got a second entry for 0.0.0.0/0 with ISP2 gateway and higher priority (thus making it the default), and all traffic went over this 2nd ISP instead of the 1st. This was not desired.

What to do ?
Make a new virtual router, for example call it “ISP2-vr” and a new zone “ISP2”. Assign your interface with the ISP2 connection to zone “ISP2” and to virtual router “ISP2-vr”. This means your automatically received default gateway is placed in the routing table of “ISP2-vr” and nothing get’s messed up.

Redirect traffic.
To redirect the desired traffic, in my case http & https, i use PBR (Policy based routing). Note the PBR should be created inside “trust-vr” virtual router, because there the traffic is originating. First we create an extended ACL. Give the ACL a number, for example 10 and assign a sequence (example number 1). In this sequence you provide the requirements. Let’s say all trafic to port 80 (http) should be redirected, then you just choose port 80, protocol TCP and leave the rest blank. Next you create a match group what basically is just an ID and name where you can assign multiple ACL’s to. Next you make an action group, where you can define an action. Now this action should be next-hop ISP2gatewayIP (this is important !) and not contain an interface. The reason is that the interface is not known to “trust-vr” virtual router so it won’t work. Combine it all in a PBR policy and assign the policy to the trust-vr.

For the next-hop action to work we need to do some tricks. First of all inside the routing table for “ISP2-vr” you need to create route like this: ISP2-gateway/32 to ISP2-gateway/32 interfaceX. Don’t ask me why but this is needed for the PBR and explained in a Juniper KB.

Now normally this should do it. But in my case my ISP2-gateway IP was not inside the ISP2-ip and subnetmask. This appears strange but is mostly the case when using PPoE. To get around this, i need to add a route in the “trust-vr” virtual router for ISP2-gatewayIP to “ISP2-vr” virtual router. That’s it PBR is operational.

You should create a policy from “Trust” zone to “ISP2” zone and allow traffic AND important enable SOURCE NAT on this policy, because your NAT set on the Trust interface won’t work because you are not routing to Untrust.

In this CLI example ethernet1 is the Trust interface, ethernet3 is the Untrust interface and ethernet4 is my ISP2.

set vrouter "trust-vr"
set source-routing enable
set sibr-routing enable
unset add-default-route
set route 0.0.0.0/0 interface ethernet3 gateway 81.246.22.xx
set route 212.71.0.yy gateway ISP2-vr
set access-list extended 20 dst-port 80-80 protocol tcp entry 1
set match-group name port80
set match-group port80 ext-acl 20 match-entry 10
set action-group name toISP2
set action-group toISP2 next-hop 212.71.0.yy action-entry 2
set pbr policy name PBRport80
set pbr policy PBRport80 match-group port80 action-group toISP2 1
exit
set vrouter "ISP2-VR"
set source-routing enable
set sibr-routing enable
set route 212.71.0.yy/32 interface ethernet4 gateway 212.71.0.yy
exit
set interface ethernet1 pbr PBRport80