VoIP communication problems over SD-WAN and IPsec-Interfaces

I will test this this weekend.

Hi,

I tested it this morning and you are right: pbrid_dir0=0 and pbrid_dir1=0. So no SD-WAN rule is applied?

But shouldn’t the rule I mention above apply to all traffic to the network?

Probable also noticed with capwap traffic routed over xgs firewall from branch office (site-2-site ipsec) to other site (site-2-site ipsec) with capwap controller.

capwap traffic is udp 5246/5247

Do you have a output of this VOIP traffic from Conntrack? 

Site1 to Site2

Rule:

[NEW] proto=udp      proto-no=17 timeout=30 orig-src=172.18.1.102 orig-dst=10.56.158.8 orig-sport=29443 orig-dport=29443 [UNREPLIED] reply-src=10.56.158.8 reply-dst=172.18.1.102 reply-sport=29443 reply-dport=29443 mark=0x4006 id=3776086656 masterid=2053321088 devin=LANuDMZ.1 devout=xfrm1 nseid=0 ips=0 sslvpnid=0 webfltid=0 appfltid=0 icapid=0 policytype=1 fwid=65 natid=0 fw_action=0 bwid=0 appid=0 appcatid=0 hbappid=0 hbappcatid=0 dpioffload=0 sigoffload=0 inzone=1 outzone=5 devinindex=633 devoutindex=45 hb_src=0 hb_dst=0 flags0=0xa0000204000 flags1=0x0 flagvalues=14,21,41,43 catid=0 user=0 luserid=0 usergp=0 hotspotuserid=0 hotspotid=0 dst_mac=00:1a:8c:5f:72:04 src_mac=00:1a:e8:89:38:51 startstamp=1654595990 microflow[0]=INVALID microflow[1]=INVALID hostrev[0]=0 hostrev[1]=0 ipspid=0 diffserv=0 loindex=45 tlsruleid=0 ips_nfqueue=0 sess_verdict=0 gwoff=0 cluster_node=0 current_state[0]=15908 current_state[1]=0 vlan_id=0 inmark=0x0 brinindex=0 sessionid=2647 sessionidrev=65067 session_update_rev=0 dnat_done=0 upclass=0:0 dnclass=0:0 pbrid_dir0=0 pbrid_dir1=0 nhop_id[0]=65535 nhop_id[1]=65535 nhop_rev[0]=0 nhop_rev[1]=0 conn_fp_id=NOT_OFFLOADED

Site2 to Site1

Rule:

[NEW] proto=udp      proto-no=17 timeout=30 orig-src=10.56.158.8 orig-dst=172.18.1.102 orig-sport=29443 orig-dport=29443 [UNREPLIED] reply-src=172.18.1.102 reply-dst=10.56.158.8 reply-sport=29443 reply-dport=29443 mark=0x8001 id=4239543104 masterid=1264079808 devin=LANuDMZ.2 devout=Port2 nseid=0 ips=0 sslvpnid=0 webfltid=0 appfltid=0 icapid=0 policytype=1 fwid=53 natid=0 fw_action=0 bwid=0 appid=0 appcatid=0 hbappid=0 hbappcatid=0 dpioffload=0xd sigoffload=0 inzone=1 outzone=2 devinindex=27 devoutindex=6 hb_src=0 hb_dst=0 flags0=0xa2000204008 flags1=0x800000 flagvalues=3,14,21,37,41,43,87 catid=0 user=0 luserid=0 usergp=0 hotspotuserid=0 hotspotid=0 dst_mac=c8:4f:86:01:4c:a2 src_mac=00:1a:e8:89:68:49 startstamp=1654595990 microflow[0]=INVALID microflow[1]=INVALID hostrev[0]=0 hostrev[1]=0 ipspid=0 diffserv=0 loindex=6 tlsruleid=0 ips_nfqueue=1 sess_verdict=0 gwoff=0 cluster_node=0 current_state[0]=6032 current_state[1]=0 vlan_id=0 inmark=0x0 brinindex=0 sessionid=4300 sessionidrev=43578 session_update_rev=1 dnat_done=0 upclass=0:0 dnclass=0:0 pbrid_dir0=0 pbrid_dir1=0 nhop_id[0]=65535 nhop_id[1]=65535 nhop_rev[0]=0 nhop_rev[1]=0 conn_fp_id=NOT_OFFLOADED

Should they disable SIP Helper? I see someone else mention another kind of traffic (capwap) and maybe issues, in which case this would be a more general issue, but turning off SIP ALG -- if it's not already off -- might be helpful. I imagine SIP ALG is only supposed to kick in when there's NAT involved, but...

So I got called back, but had real trouble to understand anything. It sounded as he was in some sort of public space, with poor connection or a defective microphone. After he wanted access to the XG the call was interrupted. I’ll asked now, if we can do the support via a chat system.

Hi,

So I got called back and we could fix this problem. In my case the routing precedence needed to be set to 1. Static, 2. SD-WAN policy routes, 3. VPN routes

I was not aware that point 3 (VPN routes) affect Tunnel interfaces. After changing it, the conntrack shows that the right rule was applied, but routed to the WAN-interface instead of the xfrm. Disable the sip system module fixed this. Thanks Wayne Folta and LuCar Toni!

So VoIP is working now, I will test our other affected services tomorrow and will let you know if it works or not.

Hi,

just tested Radius and this is weird, it works for all but for one XG.

If I use the “Test connection” button it works, but if a client wants to connect to Wi-Fi the traffic is routed to the WAN interface instead of the xfrm, but pbrid_dir0 shows the right rule. If I use a static route for the Radius server it works fine.

Next I set up a Radius server in the department, so I do not need to route the traffic, but this is weird too: a tcpdump shows that the request is given to the server, but the request is not shown in the server log. But again, if I use the “Test connection” button it works.

Hi,

I will open a new discussion for the RADIUS problem. Thanks to all of you!