Screen OS

Hey everyone. Need some help with a site to site VPN im trying to build.

Ill try to provide as many details as possible, please let me know if im missing something and any pointers would be greatly appreciated.

Site to Site VPN with a (Local) Netscreen ISG 2000 and  (Remote) Checkpoint firewall

Policy Based.

1st of all id like to confirm if this could be abug from the checkpoint's side, remote admin set hash for Phase 1 at SHA 256 and we were receiving AES_XCBC! As soon as they changed the hash to SHA1 Phase 1 came up. Weird, solved though with Sha1 so just cehcking what would have caused that.

Now with the real issue,

---All IPs and naming are fictional----

Local Peer IP - 1.1.1.1

Remote Peer Ip - 2.2.2.3/32 (Remote side has a cluster with 2 checkpoint fws 2.2.2.1/32 and 2.2.2.2/32 with VIP ip 2.2.2.3/32)

Remote site's encryption domain (192.168.10.0/24 nated to 2.2.2.3 since we do not accept private domains and since they only will be initiating traffic should be ok right?) 

Local site's encryption domain (172.10.10.11/32)

Policy created is 

Untrust Zone (2.2.2.3/32) -> trust zone (172.10.10.11/32) 

The following is an excerpt from the fws event log. Notice 2.2.2.2. Shouldnt that be 2.2.2.3? Or in that case the local id should be the private domain 172.10.10.11/32 ? 

According to the Ike events we changed the policy to 

Untrust Zone (2.2.2.2/31) -> trust zone (172.10.10.11/32) with no result.

Remote admin notified me that they could open a telnet to a specific port on our local server 172.10.10.11/32 and sa was showing  A/- for a minute or so. It then went to I/I. 

I could also provide detailed IKE debug. JHust let me know if its needed.

Thanks in advance.

A detailed IKE debug after we changed the policy to

Untrust Zone (2.2.2.2/31) -> trust zone (172.10.10.11/32)

IKE<2.2.2.3> Proxy ID match: No policy exists for the proxy ID received
## 2014-09-30 10:04:10 : IKE<2.2.2.3> Multiple proxy ID match: P2 SA <-1>
## 2014-09-30 10:04:10 : IKE<2.2.2.3> proxy-id do not match ipsec sa config
## 2014-09-30 10:04:10 : IKE<2.2.2.3> oakley_process_quick_mode():exit
## 2014-09-30 10:04:10 : IKE<2.2.2.3> Phase 2 msg-id <ba152b70>: Negotiations have failed.
## 2014-09-30 10:04:10 : IKE<2.2.2.3> Delete conn entry...
## 2014-09-30 10:04:10 : IKE<2.2.2.3> ...found conn entry(ba152b70)
## 2014-09-30 10:04:10 : IKE<2.2.2.3> IKE msg done: PKI state<0> IKE state<3/102f>
## 2014-09-30 10:04:14 : IKE<2.2.2.3> ike packet, len 392, action 0
## 2014-09-30 10:04:14 : IKE<2.2.2.3> Catcher: received 364 bytes from socket.
## 2014-09-30 10:04:14 : IKE<2.2.2.3> ****** Recv packet if <ethernet2/1.19> of vsys <Root> ******
## 2014-09-30 10:04:14 : IKE<2.2.2.3> Catcher: get 364 bytes. src port 500
## 2014-09-30 10:04:14 : IKE<2.2.2.3> Create conn entry...
## 2014-09-30 10:04:14 : IKE<2.2.2.3> ...done(new ba152b70)
## 2014-09-30 10:04:14 : IKE<2.2.2.3> Phase 2 msg-id <ba152b70>: Responded to the first peer message.
## 2014-09-30 10:04:14 : IKE<2.2.2.3> Decrypting payload (length 336)
## 2014-09-30 10:04:14 : IKE<2.2.2.3> Recv*: [HASH] [SA] [NONCE] [KE] [ID] [ID]
## 2014-09-30 10:04:14 : IKE<2.2.2.3> QM in state OAK_QM_SA_ACCEPT.
## 2014-09-30 10:04:14 : IKE<2.2.2.3> receive resp prxoy id type ID_IPV4_ADDR with mask 0: force mask to all 1.
## 2014-09-30 10:04:14 : IKE<2.2.2.3> Start by finding matching member SA (verify -1/-1)
## 2014-09-30 10:04:14 : IKE<2.2.2.3> IKE: Matching policy: gw ip <2.2.2.3> peer entry id<19>
## 2014-09-30 10:04:14 : rcv_local_addr = 1.1.1.1, rcv_local_mask = 255.255.255.255, p_rcv_local_real = 1.1.1.1
## 2014-09-30 10:04:14 : rcv_remote_addr = 2.2.2.2, rcv_remote_mask = 255.255.255.254, p_rcv_remote_real = 2.2.2.2
## 2014-09-30 10:04:14 : ike_p2_id->remote_ip = 2.2.2.2, cfg_remote_mask = 255.255.255.254, p_cfg_remote_real = 2.2.2.2
## 2014-09-30 10:04:14 : IKE<2.2.2.2> local address NOT matched.

I don't think you can get this configuration to work on the ScreenOS side.  They are using the same address for both the peer address and the nat for the tunnel traffic.  ScreenOS cannot dual use the ip addresses in that way.

the ScreenOS routing is either / or.  We can route the 2.2.2.2 out the internet for a peer or we can route the address into the encrypted tunnel, we can't do both.

Hi and Thanks for replying!

Reason we used the same ip is because we cant use private domains within our network. Since that is out of the question, remote administrator should nat and provide anothe public domain, i get that. THough, is there any other way you would suggest to do this without the remote provider natting their domain?

Thanks!

The remote side would have to nat the traffic to a different ip address than the vip and two physical addresses for the gateway.  There is no function in ScreenOS that can sort out the traffic in the way they currently have it configured.

Ok, Got it!

As it turns out though. I get the following on my log (which may imply that they are indeed sending traffic from a different Public ip)

IKE 2.2.2.3 Phase 2: No policy exists for the proxy ID received: local ID (1.1.1.1/255.255.255.255, 0, 0) remote ID (2.2.2.2/255.255.255.254, 0, 0).

Shouldn't i be receiving my local Private IP as a local ID and their 2.2.2.3/32 as a Remote ID? As this is the opposite of the policy i should have configured right? Their firewalls are in a cluster as i previously mentioned though so i dont know if that plays a role.

Please Ignore the above! Turns out Cherckpoint firewalls create an extra tunnel with the remote sides peer IP which confused us with the log messages.

Thanks again!

Is this marked as solved? How did you end up solving it?

Hi slicerpro.

Regarding on eof our issues with the peer IP being the same with the encryption domain IP we actually requested a new public IP and solved that issue. However, the reason i kept receiving errors on my log was checkpoint's fault. It had created an additional tunnel with our peer ip as the encryption domain IP resulting in 2 tunnels. 

After a session with checkpoint support they excluded that tunnel and everything worked ok.