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

[Adam]

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

[AshC73]

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]

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.  

[AshC73]

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]

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]

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

[AshC73]

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]

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]

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.  

[AshC73]

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]

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. 

[PhilipDAth]

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

[AshC73]

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]

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

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

[Adam]

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.

[Adam]

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.

[Adam]

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.

[Adam]

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

[PhilipDAth]

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