Site to Site tunnel with Checkpoint

SOLVED
AshC73
Getting noticed

Site to Site tunnel with Checkpoint

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

 

 

 

1 ACCEPTED SOLUTION
AshC73
Getting noticed

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

View solution in original post

26 REPLIES 26
Adam
Kind of a big deal

We tunnel our MX100 to a Checkpoint.  I don't have control over the Checkpoint side but I remember them saying they had to make sure the subnets matched.  On your side reference Security Appliance>Site to Site VPN and check what you have specified as the 'Private Subnets' and compare that to the Checkpoint Side.  If you don't make much headway let me know and I'll ask them exactly what they had to set on their side.  It was either the same subnets or supernetted. 

 

https://documentation.meraki.com/MX-Z/Site-to-site_VPN/Troubleshooting_Non-Meraki_Site-to-site_VPN_P...

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
AshC73
Getting noticed

Hi Adam,

Thank you for the quick reply.
Both subnets looked correct and with the traffic passing through it is very odd.
What I am going to do next which I haven't done is reboot the Fibre modem as it maybe this as it will be keeping hold of the arp and trying to pass to the ASA which isn't there.

Adam
Kind of a big deal

Will the ASA and the new Meraki be at the same IP or will the Meraki be at a new IP?  Also double check any error logs on the Checkpoint side to see if any indication of the subnets stuff. I'll check with my contact to see if he can remember what we did to clear that up.  

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
AshC73
Getting noticed

Everything is the same.

I went on Site A and ran tests again, which I was able to connect to Site B with RDP but when I tried to ping back from Site B to Site A nothing happened.

I did a packet capture on the Meraki which showed plenty of traffic to and from Site A to Site B.

I could browse the shares which are on Site B.

As soon as I switched back to the ASA everything was working again.

Its very odd as the tunnel is up but for some reason Site B is not talking to Site A.

 

4253 4.914302 192.9.200.66 192.168.2.59 TCP 1518 443 → 55382 [ACK] Seq=6512 Ack=2605 Win=64240 Len=1460 [TCP segment of a reassembled PDU]

4254 4.914644 192.9.200.66 192.168.2.59 TCP 1518 443 → 55382 [ACK] Seq=7972 Ack=2605 Win=64240 Len=1460 [TCP segment of a reassembled PDU]

4255 4.914651 192.9.200.66 192.168.2.59 TLSv1 328 Application Data

4256 4.916186 192.168.2.59 192.9.200.66 TCP 64 55382 → 443 [ACK] Seq=2605 Ack=7972 Win=17520 Len=0

4257 4.917057 192.168.2.59 192.9.200.66 TCP 64 55382 → 443 [ACK] Seq=2605 Ack=9702 Win=17520 Len=0

4258 4.918156 192.168.2.59 192.9.200.66 TCP 64 55382 → 443 [RST, ACK] Seq=2605 Ack=9702 Win=0 Len=0

 

As you can see in the packet traffic is happening and the black Bold is at the checkpoint site and the red is the meraki site.

Lots of the traffic showing.

AshC73
Getting noticed

here is a ping request from the Checkpoint site to the meraki site.

6689 11.415022 192.9.200.66 192.168.2.50 ICMP 78 Echo (ping) reply    id=0x0001, seq=17545/35140, ttl=126 (request in 6681)

Internet Protocol Version 4, Src: 192.9.200.66, Dst: 192.168.2.50
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 60
    Identification: 0x177d (6013)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 126
    Protocol: ICMP (1)
    Header checksum: 0xda1d [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.9.200.66
    Destination: 192.168.2.50
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]

Frame 6689: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 28, 2018 13:33:34.526000000 GMT Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1519824814.526000000 seconds
    [Time delta from previous captured frame: 0.000702000 seconds]
    [Time delta from previous displayed frame: 0.000702000 seconds]
    [Time since reference or first frame: 11.415022000 seconds]
    Frame Number: 6689
    Frame Length: 78 bytes (624 bits)
    Capture Length: 78 bytes (624 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:vlan:ethertype:ip:icmp:data]
    [Coloring Rule Name: ICMP]
    [Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: CiscoMer_05:a9:dd (e0:cb:bc:05:a9:dd), Dst: Dell_51:c0:31 (90:b1:1c:51:c0:31)
    Destination: Dell_51:c0:31 (90:b1:1c:51:c0:31)
        Address: Dell_51:c0:31 (90:b1:1c:51:c0:31)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: CiscoMer_05:a9:dd (e0:cb:bc:05:a9:dd)
        Address: CiscoMer_05:a9:dd (e0:cb:bc:05:a9:dd)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1
    000. .... .... .... = Priority: Best Effort (default) (0)
    ...0 .... .... .... = DEI: Ineligible
    .... 0000 0000 0001 = ID: 1
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.9.200.66, Dst: 192.168.2.50
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 60
    Identification: 0x177d (6013)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 126
    Protocol: ICMP (1)
    Header checksum: 0xda1d [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.9.200.66
    Destination: 192.168.2.50
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0
    Checksum: 0x10d2 [correct]
    [Checksum Status: Good]
    Identifier (BE): 1 (0x0001)
    Identifier (LE): 256 (0x0100)
    Sequence number (BE): 17545 (0x4489)
    Sequence number (LE): 35140 (0x8944)
    [Request frame: 6681]
    [Response time: 2.117 ms]
    Data (32 bytes)
        Data: 6162636465666768696a6b6c6d6e6f707172737475767761...
        [Length: 32]

 

Adam
Kind of a big deal

So can you ping and get replies?  And I'd mostly referenced looking at the VPN logs. 

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
AshC73
Getting noticed

I think the issue maybe the tunnel setup as another Site also uses this.

Site A - Checkpoint

 

Site B - Meraki (ASA 5510 Previous)

 

Site C - ASA 5510

 

So on the checkpoint the tunnel which has been created by the previous IT has both sites using the tunnel.

 

The error I see on the checkpoint tracker is

Scenario 3

Title: Site-to-site VPN tunnel fails with various error messages

Product: Security Gateway

Version: NGX R65, R70, R71, R75

OS: SecurePlatform, Windows

Symptoms:

  • Site-to-site VPN tunnel with 3rd party vendor fails with one or more errors in SmartView Tracker:
    • Error: "Encryption failure: packet is dropped as there is no valid SA"
    • Error: "No valid SA"
    • Error: "Encryption failure: No response from peer"
    • Error: "No proposal chosen"
  • "Invalid ID information" error in SmartView Tracker when the Security Gateway initiates a Quick Mode.
  • VPN tunnel can be initiated from one side to the other but no return traffic is seen.
  • TCPdump on the external interface shows that UDP traffic on port 500 enters the Security Gateway, but is not routed past the Security Gateway.
  • VPN tunnel becomes unstable after an 'IKE: Send Delete' packet was sent.

Summary: Phase-two Quick Mode failure occurs due to configuration/misconfiguration of VPN/encryption domain for firewalls involved in Site-to-Site VPN tunnels. Typically, this occurs when VPN domain group contains either numerous networks, or numerous hosts from different consecutive networks along with network objects. This article discusses troubleshooting the supernetting issue.

 

With two different sites uses the same tunnel with two subnets and two shared keys I think this maybe the issue as there maybe something in the config.

I removed Site C and created a new tunnel but it was a simple tunnel which users where unable to speak to Site A.

I think this tunnel was setup to work with the two ASAs at site B and C and the meraki does not like something in it.

My next step is to create a tunnel just for site B and see what happens.

What encryption does meraki like the best on phase 1 and phase 2?

 

 

 

AshC73
Getting noticed

Hi Guys,

 

Update.

 

I have create a new tunnel on the checkpoint firewall and the tunnel is now up and traffic is going before ways.

 

Only issue I have now is the voip isn't working correctly.

 

Incoming calls are received but the users cannot hear the person making the call and also they cannot make outgoing calls.

I have 1:many NATs for the ports. which is correct.

Adam
Kind of a big deal

Does the VOIP traffic go out through the internet or across the VPN tunnel?  I ask because the NAT stuff doesn't apply to the tunnel with the exception of subnet translation.  

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
AshC73
Getting noticed

It comes in through the internet.

I have a pool of public addresses which I assigned one to the voip.

1:many nats are configured for the sip port and voip range both udp.

We have a pbx on site which the voip support guys are looking into it but they don't seem to be progressing and have even which to the firewall interface address to see if that works but still one way voice and no outgoing calls.

Adam
Kind of a big deal

Maybe try the 1:1 NAT and set the 'Allowed inbound connections' to 'any' temporarily to test then you can restrict the 'Allowed inbound connections' to just the ports you want to let through. 

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
PhilipDAth
Kind of a big deal
Kind of a big deal

@Adam is right.

 

1:many NAT is 99% likely to break a SIP trunk through to a PABX.  You definitely want to use 1:1 NAT.

 

Or better yet, use SIP registration instead of a SIP trunk and then it pretty much becomes a non-issue.

Thanks Guys,

 

I cannot use 1:1 Nat as the pbx has two ip addresses which 1:1 wont let me use the public address twice, this is why I had to try with 1:many.

Currently with using the interface address I am using port forwarding.

 

example: SIP - 123.34.231.232 UDP 5060 192.168.1.1 5060 allowed addresses.

                VOIP - 123.34.231.232 UDP 19000-19400 182.168.1.2 19000-19400 allowed addresses.

 

That is I I need but not working.

The company who hosts our VOIP are the ones who are trying to get there system working.

 

As you can imagine the bosses are not happy as phones are down and my window of opportunity is nearly closed.

I have passed the information on to the voip support.

Extra long sigh

Adam
Kind of a big deal

1:Many is the right use in that case. Just make sure you have the Allowed remote IPs set to 'Any' for now until you isolate the issue. Also I'm sure it was just a typo but 182.x.x.x isn't an internal IP. I assume you meant 192.x.x.x

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
AshC73
Getting noticed

Haha yes just a typo, random addresses. 🙂

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

 

T

AshC73
Getting noticed

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.

Adam
Kind of a big deal

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

 

 

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
AshC73
Getting noticed

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.

 

Adam
Kind of a big deal

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.    

Capture.PNG

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
AshC73
Getting noticed

Thanks Adam,

 

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

 

Adam
Kind of a big deal

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. 

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
AshC73
Getting noticed

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
Getting noticed

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.

Adam
Kind of a big deal

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. 

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
AshC73
Getting noticed

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

PhilipDAth
Kind of a big deal
Kind of a big deal

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).

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels