Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
geccles
Explorer

Site to Site VPN packets getting dropped after PREIN, not logged in POSTIN

I have configured a Site to Site VPN, the tunnels come up fine and "fw monitor" shows the tunneled packets in teh PREIN (i) stage but they don't show in POSTIN (I) stage.

I have added rules to accept and log packets from the host on the far end of the VPN. There are no logs at all about the packets being dropped but they clearly don't make it from PREIN to POSTIN.

Sample output from "fw monitor"

[vs_0][fw_0] WAN:i[1253]: 152.188.27.7 -> 4.15.65.121 (UDP) len=1253 id=26360

UDP: 5060 -> 5060

[vs_0][fw_0] WAN:i[1253]: 152.188.27.7 -> 4.15.65.121 (UDP) len=1253 id=54361

UDP: 5060 -> 5060

[vs_0][fw_0] WAN:i[1253]: 152.188.27.7 -> 4.15.65.121 (UDP) len=1253 id=39253

UDP: 5060 -> 5060

The following filter is being used:

fw monitor -m iIoO -e 'accept host(4.15.65.121) or host(152.188.27.7);'

 

0 Kudos
4 Replies
PhoneBoy
Admin
Admin

The encrypted (VPN) traffic won't show past PREIN in fw monitor as decryption happens fairly early in the process.
Your filtering should also account for the unencrypted traffic IPs as well.
0 Kudos
geccles
Explorer

Hey thanks for the reply,

In the original post, I provided a stripped down filter and just a few of the packets. A more complete trace and filter is provided below.

We are tunneling SIP signaling traffic through a site to site VPN. Here is the topology:

10.0.65.122 - my local IPSec Endpoint
10.0.65.121 - my local SIP GW
10.10.28.68 - remote IPSec Endpoint
10.10.28.7 - remote SIP GW

The trace below shows the tunnel being established between 10.10.28.68 and 10.0.20.65 on port 500. "fw monitor" is showing the packets in all stages (PREIN,POSTIN,PREOUT,POSTOUT). 

The decrypted SIP packets from 10.0.28.7 to 10.0.65.121 on port 5060 are then shown but "fw monitor" doesn't show them getting past PREIN. There are no logs indicating that they were dropped. They also don't show up in the packet capture tool.

Thank you for any help you can offer.

Greg

[Expert@CHKPT]# fw monitor -m iIoO -e 'accept host(10.0.65.122) or accept host(10.0.65.121) or host(10.10.28.68) or host(10.10.28.7);'
fw: getting filter (from command line)
fw: compiling
monitorfilter:
Compiled OK.
fw: loading
fw: monitoring (control-C to stop)
[vs_0][fw_0] WAN:i[216]: 10.10.28.68 -> 10.0.65.122 (UDP) len=216 id=23791
UDP: 500 -> 500
[vs_0][fw_0] WAN:I[216]: 10.10.28.68 -> 10.0.65.122 (UDP) len=216 id=23791
UDP: 500 -> 500
[vs_0][fw_0] WAN:o[108]: 10.0.65.122 -> 10.10.28.68 (UDP) len=108 id=44009
UDP: 500 -> 500
[vs_0][fw_0] WAN:O[108]: 10.0.65.122 -> 10.10.28.68 (UDP) len=108 id=44009
UDP: 500 -> 500
[vs_0][fw_0] WAN:i[224]: 10.10.28.68 -> 10.0.65.122 (UDP) len=224 id=23813
UDP: 500 -> 500
[vs_0][fw_0] WAN:I[224]: 10.10.28.68 -> 10.0.65.122 (UDP) len=224 id=23813
UDP: 500 -> 500
[vs_0][fw_0] WAN:o[212]: 10.0.65.122 -> 10.10.28.68 (UDP) len=212 id=44010
UDP: 500 -> 500
[vs_0][fw_0] WAN:O[212]: 10.0.65.122 -> 10.10.28.68 (UDP) len=212 id=44010
UDP: 500 -> 500
[vs_0][fw_0] WAN:i[96]: 10.10.28.68 -> 10.0.65.122 (UDP) len=96 id=23814
UDP: 500 -> 500
[vs_0][fw_0] WAN:I[96]: 10.10.28.68 -> 10.0.65.122 (UDP) len=96 id=23814
UDP: 500 -> 500
[vs_0][fw_0] WAN:o[96]: 10.0.65.122 -> 10.10.28.68 (UDP) len=96 id=44011
UDP: 500 -> 500
[vs_0][fw_0] WAN:O[96]: 10.0.65.122 -> 10.10.28.68 (UDP) len=96 id=44011
UDP: 500 -> 500
[vs_0][fw_0] WAN:i[376]: 10.10.28.68 -> 10.0.65.122 (UDP) len=376 id=23831
UDP: 500 -> 500
[vs_0][fw_0] WAN:I[376]: 10.10.28.68 -> 10.0.65.122 (UDP) len=376 id=23831
UDP: 500 -> 500
[vs_0][fw_0] WAN:o[320]: 10.0.65.122 -> 10.10.28.68 (UDP) len=320 id=44012
UDP: 500 -> 500
[vs_0][fw_0] WAN:O[320]: 10.0.65.122 -> 10.10.28.68 (UDP) len=320 id=44012
UDP: 500 -> 500
[vs_0][fw_0] WAN:i[80]: 10.10.28.68 -> 10.0.65.122 (UDP) len=80 id=23834
UDP: 500 -> 500
[vs_0][fw_0] WAN:I[80]: 10.10.28.68 -> 10.0.65.122 (UDP) len=80 id=23834
UDP: 500 -> 500
[vs_0][fw_0] WAN:i[1233]: 10.10.28.7 -> 10.0.65.121 (UDP) len=1233 id=8489
UDP: 5060 -> 5060
[vs_0][fw_0] WAN:i[1233]: 10.10.28.7 -> 10.0.65.121 (UDP) len=1233 id=26944
UDP: 5060 -> 5060
[vs_0][fw_0] WAN:i[1233]: 10.10.28.7 -> 10.0.65.121 (UDP) len=1233 id=21061
UDP: 5060 -> 5060
[vs_0][fw_0] WAN:i[1233]: 10.10.28.7 -> 10.0.65.121 (UDP) len=1233 id=10653
UDP: 5060 -> 5060

0 Kudos
PhoneBoy
Admin
Admin

There's an option in fw monitor that shows exactly what chain the packets get to (-p all)—might be helpful.
You will probably have to do some debugs to see exactly why it's dropping.
Highly recommend getting the TAC involved here.
0 Kudos
Maarten_Sjouw
Champion
Champion

Could it be that the VOIP protocol is just being dropped as a lot of those protocol based services cause drops while you think it should be allowed. check with 'fw ctl zdebug drop | grep 10.0.65.12' to see why it is dropping.
Regards, Maarten
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events