Screen OS

I am able to setup a VPN for a remote user using the NCP Secure Client Juniper Edition software to a Juniper SSG5 on Firmware 6.2. I would like to then forward traffic to a certain IP address from the remote user to the SSG5 which would then forward this on to another Juniper VPN device.

 

For example

Remote User Internal IP Address 10.10.10.1

 

Juniper VPN 1 Untrust 1.1.1.1

Trust 192.168.1.1

 

Juniper VPN 2

Untrust 1.1.1.2

 

End IP Address to be reached 2.2.2.2

 

The remote user can access addresses in the range 192.168.1.x but not the 2.2.2.2 address.

 

There is a route already set up between Juniper VPN 1 to Juniper VPN 2 for traffic to 2.2.2.2. This is working fine. I have been able to setup Hub and Spoke VPNs for other Juniper VPN devices but the dialup user is proving to be very difficult.

 

 

 

Hi,

 

Have you added 2.2.2.2 as a remote network to the client configuration?

Have you configured the Untrust-to-Untrust policies for 10.10.10.1 and 2.2.2.2? I assume that you use Block intrazone traffic in Untrust zone which is a default option for Untrust zone.

 

Hello,

 

First of all I assume you have configured both the VPNs as route based.

 

Then along with suggestions mentioned by Edouard you need to configure a policy and route on the remote site to allow this Dial Up subnet.

Hi Edouard

 

The 2.2.2.2 address was already added as a remote network in the client software configuration. I have left the intrazone traffic blocked for the Untrust zone as per the default settings.

 

With my other hub and spoke VPNs, they have all been setup as route based VPNs and they all use Juniper Hardware at either end.

 

I have tested a policy based and a route based VPN setup for a dial up user.

 

For the policy based setup I have 1 policy for this dial up VPN which is from Dial Up to 192.168.1.1 action tunnel down the dial up VPN. This allows a remote user to access addresses in the range 192.168.1.x.

 

When I tried setting up another policy Untrust to Untrust for the Dial Up VPN to 2.2.2.2 I receive an error 'Dialup-VPN must use IPSEC or L2TP in policy.'

 

With the route based setup I had to use 255.255.255.255/32 as the Remote IP Address for the Dialup VPN. I then entered this address in the client software and a remote user was able to access addresses in the range 192.168.1.x again.

 

But as before when trying to setup a policy to allow the Untrust to Untrust access (Dial up VPN to 2.2.2.2) Action Permit I come across the error 'Dialup-VPN must use IPSEC or L2TP in policy' again.

 

Regards

Simon

 

 

 

 

Hi Simon,

 

You wont be able to configure a policy from untrust to trust with source as "Dialup Any"
.

 

What you need to do here is create a route based dialup VPN the way you created.

Enter this second subnet on the remote client.

 

Then disable intrazone block on 'Untrust' Zone and this setup should work.

Or else if you dnt want to disable intra zone block for untrust zone then you can configure a policy from

untrust to untrust with source as "Any' or " the network specified in Dialup pool for this remote client and destination as 2.2.2.2/32.

Hi Sarab

 

I unticked the Block Intra-Zone Traffic for the Untrust Zone. I then added a Policy Untrust to Untrust Any to 2.2.2.2 Permit. With this policy I tried setting it up the same way as our hardware VPN hub and spokes with NAT source translation Use Egress Interface IP turned on.

 

The remote software is set with Ipsec Address Assignment as the local IP address which would be a dynamic IP address assigned to the remote user, in this case it was 192.168.20.3

 

This gave me the same result, the ability for a remote user to acces 192.168.1.x but not 2.2.2.2.

 

In the log for the Juniper device at the 192.168.1.x network I could see the following messages:

 

IKE x.x.x.x Phase 2: No policy exists for the proxy ID received: local
ID (2.2.2.2/255.255.0.0, 0, 0) remote ID (192.168.20.3/255.255.255.255, 0,
0).

Rejected an IKE packet on ethernet0/0 from x.x.x.x to
1.1.1.1 with cookies 380d5e200eadf417 and 6f6be3a2da4e63bd because The
peer sent a proxy ID that did not match the one in the SA config

 

Regards

Simon

 

 

 

It appears on the remote client you need to configure two VPN, one for 192.x.x.x and other for 2.2.2.2. The same thing on netscreen side. Or else the other solution would be send all traffic from Client ( including internet) to firewall. Use remote IP as 0.0.0.0/0 on client.

Hi Simon,

 

There is definitely a Proxy ID mismatch. But, anyway, ScreenOS 6.2 does not support multiple Proxy IDs with route-based VPN. You should consider switching to ScreenOS 6.3. Another option would be to forward all traffic through the tunnel as recommended by Sarabjeet. The proxy ID 255.255.255.255/32 - 0.0.0.0/0 does this work. Sure, you need a policy(ies) for the Internet access with a source-NAT on them.

You can also try to configure a MIP on the tunnel interface: MIP 192.168.1.x - Host 2.2.2.2/32. I had used this trick in the past, before ScreenOS 6.3 has appeared.

I recommend to enable logging on all policies and also run debug flow basic.

Hi Edouard

 

I upgraded the OS to 6.3.0r12 and am still running into the same problem.

 

With the remote software, to have the VPN working at all I need to either set the IPsec Address Assignment to manual IP which cannot be 0.0.0.0 or 255.255.255.255 or set it to local IP address which is the address assigned to the remote user.

 

I enabled logging for all the policies. In the log file the same messages are being displayed:

 

IKE x.x.x.x Phase 2: No policy exists for the proxy ID received: local ID (2.2.2.2/255.255.0.0, 0, 0) remote ID (192.168.20.3/255.255.255.255, 0, 0).

Rejected an IKE packet on ethernet0/0 from x.x.x.x to 1.1.1.1 with cookies f9c36df639a55c4e and f5a176aeb12eb8c2 because The peer sent a proxy ID that did not match the one in the SA config

 

Regards

Simon

Hi Simon,

 

The preffered method to assign IPs to the dialup users is an IP pool on the FW. The IP assignment is a part of XAUTH.

The local IP can also be used but this is not a good approach, especially if you have multiple users which may have overlapping local addressing or use many different IP networks. 

You can decide if the users always get the same IPs or different pool IPs in a round-robin manner. In any case you have a full control over addressing and routing, if an IP pool is used.

Neither 0.0.0.0 nor 255.255.255.255 can be assigned and this is not required.

 

You should configure the remote networks under the Split Tunneling section on the NCP client. These might be in your case 192.168.1.0/24 and 2.2.2.2/32 (2.2.2.2/255.255.0.0 is incorrect, unless you mean 2.2.0.0/255.255.0.0).

 

The matching Proxy IDs on the FW are:

255.255.255.255/32 - 192.168.1.0/24

255.255.255.255/32 - 2.2.2.2/32

 

The 255.255.255.255/32  means here something like "any single IP seen through the tunnel".

The access policies should be configured with the assigned IPs rather than 255.255.255.255/32.

An excelent step-by-step NCP configuration guide is here:

http://www.ncp-e.com/fileadmin/pdf/service_support/NCP_QuickInstallationGuide-NCPwithJuniperScreenOS.pdf

Just ignore what is said regarding the policy based VPN.

Hi Edouard

 

Thanks for pointing me in the right direction, I was finally able to setup the hub and spoke VPN for a remote user. The NCP configuation guide was really useful. The VPN is setup as a route based VPN, the key points I needed to address were:

 

Upgrade the Firmware to 6.3 to allow multiple Proxy IDs - this was really helpful

Use IP Pool for the Dial up User

Setup a Policy to allow the IP Pool Addresses to Access the  2.2.0.0/255.255.0.0 (I used source translation here as well)

 

Overall very pleased with the outcome. Thanks to Sarab as well for your help.

 

Kind Regards

Simon