Site to Site tunnel with Checkpoint

[AshC73]

Hello,

I am having a few issues with a tunnel I have created between my mx84 and a Checkpoint firewall.

The MX is replacing an old ASA 5510 which the tunnels currently is fine.

Site A is MX

Site B is Checkpoint

When I switch to the MX then tunnel comes up and traffic is passing through from the site A to site B including pinging and remote connection, but when I try from Site B to Site A nothing is happening, no pings, no RDP etc.

As soon as I put the ASA back traffic passes both ways.

msg: failed to pre-process ph2 packet (side: 1, status: 1).

msg: failed to get sainfo

I am seeing lots of the above errors which I have looked the KB and it says mismatch subnet but I have checked and are correct.

What is odd is that users at Site A can access mail and applications which come from Site B so the tunnel is working but I don't get why I am unable to connect to Site A???

If anybody has any ideas or solutions your help will be greatly appreciated.

Regards, Ash

[AshC73]

Haha yes just a typo, random addresses. 🙂

Hopefully the voip engineer will come back with some fix tomorrow morning.

T

[AshC73]

Still not luck.

I have had to connect the old asa firewall back in as phones have been down for a full working day.

As soon as the ASA connected and the arp cleared the phones started working.

Sip inspection is on with the asa but I don't think that really matters as the meraki is replacing this fw.

so I have provided the information (changed addresses) which have been given.

11.222.33.0 /24 SIP Main to internal IP address of pbx and pbx dsp

11.222.34.0 /24 SIP Failover to internal IP address of pbx and pbx dsp

Open Ports

5060 UDP to internal IP of PBX

16000 – 16200 to internal IP of DSP

Port re-direct from 8888 to internal port 443 pointed at IP of pbx

Also need

444.55.66.88 allowed to internal IP of PBX

IP’s

192.168.2.216 is the internal Address of the PBX

192.168.2.217 is the internal address of the DSP

UDP 16000>16171 to 192.168.2.217

UDP 5060 (SIP) to 192.168.2.216

TCP 8888 to 192.168.2.216.

Return traffic from .216 & .217 will originate from 22.300.256.115.

All other traffic will originate from 22.300.256.114.

All outbound traffic is allowed.

If you are having issues with your SIP based phone system, you will need to look at how the Meraki handles SIP traffic.

[simple818]

I'm not following your exact configuration here. In your words what needs to be NAT'd to where? So far I'm seeing a Many:1 NAT?

11.222.33.0 /24 to 192.168.2.216

[AshC73]

Meraki is on .114

Voip is on .115

PBX is on 216

DSP is on 217

Open ports

5060 UDP to internal ip of PBX

16000-16200 UDP to Internal ip of DSP

SIP 11.222.33.0 /24 to internal address of PBX

so I have created a 1:Many NAT

Public address: 22.300.256.115

Description Protocol Pub port Lan IP Local Port Allowed Remote IPS.

SIP UDP 5060 192.168.2.216 5060 11.222.33.0 /24, 11.222.34.0 /24

VOIP UDP 16000-16200 192.168.2.217 16000-16200 11.222.33.0 /24, 11.222.34.0 /24

Hope this makes sense.

[simple818]

So all of the traffic coming to your SIP IP from outside the network is coming from 11.222.33.0 /24, 11.222.34.0 /24? And it is going to 22.300.256.115?

A simple test case would be to create a 1:1 NAT to make sure you have the basics in order. This should let you ping the PBX from any external IP. You could change the LAN IP to .217 to do the same test to the DSP. I think it would be good to make sure that the traffic is actually passing through the MX to the LAN devices before creating more complex NAT rules.

[AshC73]

Thanks Adam,

I will be testing this Sunday as the office will be empty.

[simple818]

Agreed, at this point you probably don't want to keep being disruptive. This test assumes the endpoint device doesn't have a firewall prohibiting pings so make sure to factor that in. You can also do captures on the MX from the WAN (Internet) and LAN sides of the device to see if your pings are getting through.

[AshC73]

Hi Adam,

I have just got my ISP to turn SIP Inspection off on the cisco ASA so I could test the phones.

As soon as it was disabled the same symptoms happened, one way audio and not outgoing calls.

I then got it switched back on and phones started working correctly.

This must mean the issue is with SIP ALG on the PBX.

[AshC73]

I ran the ping test today which was successful both ways.

Meraki Support ran the tests and took a packet capture both Lan and Wan which showed the ping response.

This proves the meraki is passing traffic down the .115 and with the SIP Inspection test last week, now all points to the pbx.

Not sure what the voip supplier will come back with but ill have to wait on them for some form of solution.

[simple818]

At the very least that will give you more clarity. Next step would be to NAT the actual traffic you need through or testing. That test was just ping traffic.

[AshC73 · Accepted solution]

Sorry for the delay on an update, its been pretty hectic.

Well I got the meraki working with the phones!! Turns out it was the PBX box, the sip providers forgot there was a fault with the box when it was first installed and with the ASA working with SIP ALG enabled that just left it and never got round to fixing it.

Thank you for all your help

[Philip D'Ath]

It sounds like you have a phase 2 mis-match. Double check:

* Encryption domains

* Selected crypto algorithyms

* Phase 2 lifetime (I think Checkpoints are a bit sensitiive to this one as well).