SRX

Hi

I am aware that in policy based vpn we don't need to set up proxy IDs but I wanted to play around with it to see how it works if you do. 

So I manually set up proxy id as local 1.1.1.1/32 and remote 2.2.2.2/32 on SRX

The other end is ASA

[edit security ike]
sadm@SRX240# show
traceoptions {
flag ike;
}
proposal Phase1-Proposal {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
}
policy IKE_Policy {
proposals Phase1-Proposal;
pre-shared-key ascii-text "$9$MuuLXNUDkQz6.P1hSyKvoJZj.Pz36pO1"; ## SECRET-DATA
}
gateway bharat-gw {
ike-policy IKE_Policy;
address 10.102.101.164;
external-interface ge-0/0/15.0;
}

[edit security ipsec vpn IPSEC-Tunnel-To-Bharat ike]
sadm@SRX240# show
gateway bharat-gw;
inactive: proxy-identity {
local 1.1.1.1/32;
remote 2.2.2.2/32;
}

Now as per my understaing  it should be sending 1.1.1.1 and 2.2.2.2 as proxy IDs to the ASA.

But instead it's sending 0.0.0.0 to the ASA

Mar 01 2013 11:20:52: %ASA-7-714011: Group = 10.102.100.115, IP = 10.102.100.115, ID_IPV4_ADDR_SUBNET ID received--0.0.0.0--0.0.0.0
Mar 01 2013 11:20:52: %ASA-7-713035: Group = 10.102.100.115, IP = 10.102.100.115, Received remote IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0
Mar 01 2013 11:20:52: %ASA-7-715047: Group = 10.102.100.115, IP = 10.102.100.115, processing ID payload
Mar 01 2013 11:20:52: %ASA-7-714011: Group = 10.102.100.115, IP = 10.102.100.115, ID_IPV4_ADDR_SUBNET ID received--0.0.0.0--0.0.0.0

Mar 01 2013 11:20:52: %ASA-3-713061: Group = 10.102.100.115, IP = 10.102.100.115, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside

[edit security policies]
sadm@SRX240# show
from-zone trust to-zone untrust {
policy outbound {
match {
source-address internal_host;
destination-address Bharat-internal-host;
application any;
}
then {
permit {
tunnel {
ipsec-vpn IPSEC-Tunnel-To-Bharat;
}
}
log {
session-init;
session-close;
}
}

from-zone untrust to-zone trust {
policy inbound-top {
match {
source-address Bharat-internal-host;
destination-address internal_host;
application any;
}
then {
permit {
tunnel {
ipsec-vpn IPSEC-Tunnel-To-Bharat;
}
}
log {
session-init;
session-close;
}
}
}

If I remove proxy ids VPN comes up fine and passes to traffic. But I wanted to see and confirm that 1.1.1.1 and 2.2.2.2 will be sent as proxy IDs and I should be able to see that on ASA logs but I see 0.0.0.0 being received by ASA 

And I wish to understand why?

Any ideas?

Thanks!

For policy-based VPNs, the proxy-ID is derived from the security policy. From the security policy, the local address
and remote address are derived from the address book entries, and the service is derived from the application configured for thepolicy.

I hope it clarifies.

Regards,

Deepak

Hi

Thanks for your reply. But if that's the case then why does setting proxy ids as shown above immediately starts sending 0.0.0.0 as proxy ids to the ASA?

If proxy IDs are always derived from the policy then why do we have an option of setting those for policy based VPN?

Thanks!

Any Ideas?

Hi

It looks like your proxy id's are deactivated in the config (tag "inactive:"). Try to activate them (use "activate" command).

Hi

When it's inactive it works fine and sends the right proxy ids across but when you remove inactive it sends 0.0.0.0 instead of the proxy ids mentioned.

Why is that?

Hi

By right proxy ids, do you mean ones derived from policy?
Im not sure why you see 0.0.0.0 when you have proxy id
manually configured, can you post your full config?

Hi

FW config is attached in the comment.

It should be sending 1.1.1.1 and 2.2.2.2 as proxy ids to ASA even though it's a policy based VPN since they are manually set up. But it sends 0.0.0.0 to ASA as proxy ID and I am trying to understand why.

Thanks!

Attachment(s)

SRX config.txt   11 KB 1 version

Your proxy IDs need to match the networks that you are sending on both sides of the tunnel, you have them defined as /32 host addresses which don't match the addresses being matched by the policy.

My suspicion is that Junos is seeing that the Proxy IDs aren't correct and falling back to sending 0.0.0.0.

The ASA is going to match based on an ACL for what Cisco likes to call "interesting traffic" -- and by looking at your SRX config I assume the ACLs on the ASA match for 192.168.200.5/32, which is what it's going to send in its Proxy ID.

Try setting your proxy IDs to local: 172.19.22.5/32   and remote:  192.168.200.5/32

(also curious why your "Bharat-internal-net" is 172.19.20.0/24 but the "Bharat-internal-host" 192.168.200.5/32 -- not in the network range)

Hi

Thanks for your reply.

My understanding was that SRX should send whatever is set up in the proxy id section across as proxy ids irrespective of what's set in the policy a.k.a. setting up proxy ids manually overrides srx derriving them from policies in policy based vpn.

But that doesn't seem to be case?

---

@ronydc86 wrote:

 

My understanding was that SRX should send whatever is set up in the proxy id section across as proxy ids irrespective of what's set in the policy a.k.a. setting up proxy ids manually overrides srx derriving them from policies in policy based vpn.

---

Well, as I mentioned, that was my suspicion.  I don't know for sure if that's what's happening in this case, I would say that a JTAC or other employee would have to verify one way or another as to the behavior in this scenario.

Regardless, though, what you have isn't going to work.  At least not without some kind of extreme trickery on both ends of the tunnel, and I don't know why you'd do that when the simple solution is to just set your proxy IDs correctly.

Juniper devices are somewhat liberal with proxy IDs -- Cisco devices are not.  Cisco devices don't like things that Juniper firewalls will allow, such as proxy IDs of 0.0.0.0.  The Cisco is going to expect proxy IDs that match the ACLs that are configured for the crypto map on the ASA.  If you're tunneling 1.1.1.0/24 local to 2.2.2.0/24 remote, then your proxy IDs should say exactly that.

Ok... I think I see what you're saying here.

You're experimenting and the setting isn't behaving as you expect it to.

I've never tried to set a proxy ID with a /32.  Maybe it's a bug, maybe it's "behavior as designed."  Consult JTAC.

Perhaps my theory is correct and the proxy ID being outside the range of matched tunnel traffic is causing some kind of fallback to compatibility and sending 0.0.0.0.  I don't know if the SRX is supposed to send any arbitrary value that's configured for proxy ID, or if there is some sanity checking going on behind the scenes.  Consult JTAC.

Try setting some proxy IDs that fall within the tunneled networks.  For example, given this information:

internal_net 172.19.22.0/24;
internal_host 172.19.22.5/32;

Bharat-internal-net 172.19.20.0/24;
Bharat-internal-host 192.168.200.5/32;

... you could try setting your VPN policies to match the network addresses, and then set your proxy ID to host addresses that fall within those /24 networks and see if that changes the behavior.

Hi All

I did a quick lab test and in my case SRX always sends local/remote addresses taken from security policy for a policy based VPN, and I can't override it with proxy-id knob at all. It never sends zero, however...

I know it will send 0.0.0.0 if you will use an address-set as source (destination) address in your security policy, but this is not our case here.

So your device's behavior is not clear for me. But I also guess that if you move to route based VPN (which is more flexible and genearlly preferred), manual setting of proxy id should work.

Hi

Thank you both for your replies!

It's just a lab scenario to test out how it works.

Setting up proxy IDs that fall within the actual enc domain range didn't help. It's still sending 0.0.0.0 as proxy IDs and I am not quite sure why?

I know that route based would be much easier but I wanted to test out this scenario in the lab to see how it works.