Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Subscribers 27 subscribers
  • Views 3612 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

fw_rule_id=0 blocking initial ipsec site-to-site VPN traffic on VOIP phone only

wineoh

I have an IPSEC site-to-site VPN working with my XG 125 and an old Sonicwall. All connections seem to work fine to the XG except the VOIP phone I use at the Sonicwall side. When anyone first calls me or I call out with it, packets are dropped by the XG and there is a fast-busy. After that, if somebody calls, the VOIP seems to work fine. It's as if the XG initally blocks the UDP 4000. Firewall rules on both ends are at the top and allowing VPN any (autoadded rules by XG).

I've already applied https://community.sophos.com/kb/en-us/127785 and https://community.sophos.com/kb/en-us/123523 with no change.

This is the dropped packet capture:

2018-11-14 13:19:10 0101021 IP 192.168.7.3.4000 > 192.168.0.248.4000 : proto UDP: packet len: 24 checksum : 19952
0x0000:  45c0 002c 0095 0000 3f11 f120 c0a8 0703  E..,....?.......
0x0010:  c0a8 00f8 0fa0 0fa0 0018 4df0 0101 0000  ..........M.....
0x0020:  0000 0400 0000 043b 0000 0006            .......;....
Date=2018-11-14 Time=13:19:10 log_id=0101021 log_type=Firewall log_component=Firewall_Rule log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=ipsec0 out_dev=br0 inzone_id=5 outzone_id=0 source_mac=b4:de:31:2b:ec:19 dest_mac=7c:5a:1c:78:f0:9d l3_protocol=IP source_ip=192.168.7.3 dest_ip=192.168.0.248 l4_protocol=UDP source_port=4000 dest_port=4000 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 proxy_flags=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 inmark=0x200 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drop_fix=0 ctflags=0 connid=831720704 masterid=0 status=256 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A

 



This thread was automatically locked due to age.
Parents Reply
  • +1 in reply to FloSupport

    No, we do not have disconnect when idle enabled.

    I just tried "set advanced-firewall bypass-stateful-firewall-config add source_host 192.168.x.x dest_host 192.168.x.x" on the console.

    So far the results have been positive. The source_host here is the IP phone over the VPN and destination is the VOIP system on the other site-to-site end (different subnets).

    The challenge with testing this, as mentioned before, is if they at first get the fast busy signal and call back, the second call works. Then there's an unknown period of time when the subsequent calls work just fine. So I may not know if the above worked until I try again tomorrow morning, for example.

Children