Screen OS

Hi Guys,

I have a question in regards to configure the proxy id for route base vpn.

How does it works? I know the proxy id has to match between two firewall for the tunnel to be able to come up, is that correct?

Also lets say I have proxy id set up X.X.X.X/32 (local) - Y.Y.Y.Y/32(remote) - ANY

Is that mean even if I have a policy set up allowing entire X.X.X.X/24 to Y.Y.Y.Y/32 - ANY I won't be able to access it from host X.X.X.X+1 ??

Will the proxy id has to match the policy between my TRUST and VPN?

The firewall is SSG550M

Thanks,

Dom

For Juniper to Juniper tunnels you can leave the proxy-id empty and the tunnels will come up with 0.0.0.0/0 as the pair allowing any traffic that is routed to the tunnel to transit.  This is the prefered method for route based vpn.

You would then control access via the policies on both sides of the tunnel.

If one side of the tunnel is not Juniper then they may not support open proxy-id so you would have to create matching pairs.

Hi Spuluka,

This is Juniper to Cisco/Sonicwall/Anything but not Juniper...

So I understand that I will need to set proxy id and it will have to match it on both sides. 

The thing I'm not sure about is if I set the following proxy id on both sides:

10.20.30.45/32 (Local ID) - ANY - 192.168.1.0/24 (Remote ID)

the tunnel is coming up sucessfully.

With the policy configured from Trust --> VPN like this:

10.20.30.0/24 (source) - ANY - 192.168.1.0/24 (destination)

Should I be able to ping any host in 192.168.1.0/24 from any host in 10.20.30.0/24 or because of proxy id only from host 10.20.30.45??

Do I need to match proxy id setup with policy set up?

Thanks,

Dom

Got it.

The /32 on the proxy will prevent access from anyone else on the /24 except the host 45 in the proxy id.

The policy and the proxy-id will work together with the most restrictive parameter will win.

---

@spuluka wrote:

Got it.

 

The /32 on the proxy will prevent access from anyone else on the /24 except the host 45 in the proxy id.

 

The policy and the proxy-id will work together with the most restrictive parameter will win.

---

This is not the case for a route-based VPN. With a route-based VPN, the proxy-IDs are used only for tunnel negotiation, not for traffic restriction.

Having said that, if the other end is policy-based (e.g. a Cisco ASA using crypto maps), then the traffic will not be permitted on that side.

This is not the case for a route-based VPN. With a route-based VPN, the proxy-IDs are used only for tunnel negotiation, not for traffic restriction.

 On a practical level the proxy id has the same effect whether the vpn is route or policy based.  If the traffic does not match the proxy id pair configured it cannot enter the tunnel.

Whether you want to call this a tunnel negotiation and I call it a restriction, doesn't matter.  The practical effect is that the proxy id pair is one of the two "restrictions" for the traffic.

The second restriction is the policy configured on the device.  With a policy based vpn, the policy creates the proxy id pair so they are always the same.  With the route based tunnel they are usually different.

So my point is that the MOST restrictive configuration will "win" whether that is the policy or the proxy id pair.  In the case in this question the proxy id was the most restrictive using the single host.  So this prevented other subnet addresses from crossing the tunnel.

---

@spuluka wrote:

 

If the traffic does not match the proxy id pair configured it cannot enter the tunnel.

 

---

This is incorrect. You can test it yourself as follows:

Set up a couple of SSGs, e.g. 'site A' and 'site B'. Site A's internal range is 10.1.1.0/24, site B is 10.2.2.0/24. Configure a route-based VPN, but use an incorrect proxy-ID pair (e.g. 192.168.1.0/24 for site A, 192.168.2.0/24 for site B). Configure correct routes pointing to the respective tunnel interfaces (i.e. on site A you add a route toward 10.2.2.0/24 pointing toward tunnel.1 or whatever, and vice versa on site B). Configure any necessary firewall policies.

Despite the fact that the traffic does not match the configured proxy-IDs, the tunnel will come up and traffic will pass.

Spud,

As noted in this thread the tunnel discussed is between Juniper and third party devices.  These will not encrypt and send traffic outside the proxy id pairs configured.

---

@spuluka wrote:

 

As noted in this thread the tunnel discussed is between Juniper and third party devices.  These will not encrypt and send traffic outside the proxy id pairs configured.

---

This is true for some non-Juniper devices (particularly devices that can perform only policy-based tunnelling such as Cisco ASAs), but not for all. For example, route-based VPNs on Palo Alto Networks devices behave the same way as on Junipers (i.e. traffic does not have to match the proxy-IDs). The same applies to a VTI-based VPN on a Cisco ISR. I haven't had an opportunity to test with a route-based VPN on a Sonicwall, but I would suspect the same would apply here too (if anyone here has a Sonicwall, I'd be interested in the results!)

Hi Dom,

Pl check  here to get the information about proxy ID.

http://forums.juniper.net/t5/SRX-Services-Gateway/Proxy-id/m-p/72164/highlight/true#M8390

And

Proxy IDs that identify the traffic to be encrypted are negotiated.The proxy IDs that identify what traffic is part of the VPN.

Proxy IDs negotiation: A proxy ID is a mechanism for identifying the traffic carried within
the VPN, and it contains two components: the local and remote IP prefix, and the
service. Within IKE version 1, only a single prefix can be defined per local and remote
IP value, along with a single service.

Strictly speaking, the proxy IDs do not really need to match the traffic at all, but both
parties must match what they are negotiating in the VPN. Proxy IDs have long been
considered a nuisance when configuring VPNs because they are not really needed, and
in large part because different vendors have determined the proxy IDs differently. There
is an exception to this that was supported in ScreenOS (multiple proxy IDs), but this
isn’t supported today in the SRX.

The issue is that the proxy IDs are defined within the IKE RFC, which strictly defines
how they are formatted and what they contain. However, the RFC doesn’t exactly state
how the proxy IDs should be derived, and therefore vendors have interpreted this differently.
Ultimately, this has caused interoperability issues when trying to establish VPN
tunnels, so be advised that some tuning might be required.

Best Regards,

Suresh

Suresh

This is actually I was looking for.

Thanks a lot.

The reason I came up with this question was because I have been asked to allow another host via our exisitng route based vpn and after I have done that, I couldn't get it connected.

Once I have created additional proxy id entry everything started working.

Thanks,

Dom 

Thanks Dom!!