core icon indicating copy to clipboard operation
core copied to clipboard

OPNsense drops SIP-Invite-Traffic with Rule Allow Any To Any

Open SiJux opened this issue 2 years ago • 3 comments

Hello,

today I have a strange issue with SIP-Invite-Traffic.

I have 2 Networks (Client, VOIP) which are VLANs terminating on the OPNsense. Also I have a OpenVPN-Network. Firewall-Rules are configured to allow any traffic from any to any network:

Client -> ANY : ANY -> ANY VOIP -> ANY : ANY -> ANY VPN -> ANY : ANY -> ANY

If I'm connected to the VPN with my Notebook via a Hotspot I can use linphone to start SIP-Calls to internal and external numbers: Notebook -> VPN -> Linphone --> Internal/External Call : works Also it is possible to receive calls on my notebook.

If I switch to my Client-Network it's not possible to start SIP-Calls. The other way, to receive calls, works fine. Notebook on Client-Network -> Linphone --> Internal/External Call : does't work

Now I've captured the Network-Traffic an found an strange behaviour:

The SIP-Invite-Packages AFTER "Proxy Authentication Required" are dropped by the Firewall:

# Traffic from Client to Firewall 19:17:03.432009 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 1300: 192.168.160.29.sip > 192.168.140.140.sip: SIP: INVITE sip:[email protected] SIP/2.0 19:17:03.436012 f4:90:ea:00:6d:e6 (oui Unknown) > 00:50:b6:ba:e6:f0 (oui Unknown), ethertype IPv4 (0x0800), length 321: 192.168.140.140.sip > 192.168.160.29.sip: SIP: SIP/2.0 100 Trying 19:17:03.437946 f4:90:ea:00:6d:e6 (oui Unknown) > 00:50:b6:ba:e6:f0 (oui Unknown), ethertype IPv4 (0x0800), length 736: 192.168.140.140.sip > 192.168.160.29.sip: SIP: SIP/2.0 407 Proxy Authentication Required 19:17:03.474871 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 478: 192.168.160.29.sip > 192.168.140.140.sip: SIP: ACK sip:[email protected] SIP/2.0 19:17:03.475040 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 1514: 192.168.160.29.sip > 192.168.140.140.sip: SIP: INVITE sip:[email protected] SIP/2.0 19:17:03.475044 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: udp 19:17:03.993408 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 1514: 192.168.160.29.sip > 192.168.140.140.sip: SIP: INVITE sip:[email protected] SIP/2.0 19:17:03.993412 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: udp 19:17:04.994034 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 1514: 192.168.160.29.sip > 192.168.140.140.sip: SIP: INVITE sip:[email protected] SIP/2.0 19:17:04.994037 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: udp 19:17:06.994025 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 1514: 192.168.160.29.sip > 192.168.140.140.sip: SIP: INVITE sip:[email protected] SIP/2.0 19:17:06.994028 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: udp 19:17:10.993903 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 1514: 192.168.160.29.sip > 192.168.140.140.sip: SIP: INVITE sip:[email protected] SIP/2.0 19:17:10.993909 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: udp 19:17:28.105569 00:50:b6:ba:e6:f0 (oui Unknown) > f4:90:ea:00:6d:e6 (oui Unknown), ethertype IPv4 (0x0800), length 60: 192.168.160.29.sip > 192.168.140.140.sip: SIP

# Traffic from Firewall to pbx 19:16:58.101090 f4:90:ea:00:6d:e6 > 00:09:52:04:2d:b4, ethertype IPv4 (0x0800), length 60: 192.168.160.29.sip > 192.168.140.140.sip: SIP 19:17:03.431676 f4:90:ea:00:6d:e6 > 00:09:52:04:2d:b4, ethertype IPv4 (0x0800), length 1300: 192.168.160.29.sip > 192.168.140.140.sip: SIP: INVITE sip:[email protected] SIP/2.0 19:17:03.435611 00:09:52:04:2d:b4 > f4:90:ea:00:6d:e6, ethertype IPv4 (0x0800), length 321: 192.168.140.140.sip > 192.168.160.29.sip: SIP: SIP/2.0 100 Trying 19:17:03.437554 00:09:52:04:2d:b4 > f4:90:ea:00:6d:e6, ethertype IPv4 (0x0800), length 736: 192.168.140.140.sip > 192.168.160.29.sip: SIP: SIP/2.0 407 Proxy Authentication Required 19:17:03.474519 f4:90:ea:00:6d:e6 > 00:09:52:04:2d:b4, ethertype IPv4 (0x0800), length 478: 192.168.160.29.sip > 192.168.140.140.sip: SIP: ACK sip:[email protected] SIP/2.0 19:17:03.474657 f4:90:ea:00:6d:e6 > 00:09:52:04:2d:b4, ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: ip-proto-17 19:17:03.993061 f4:90:ea:00:6d:e6 > 00:09:52:04:2d:b4, ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: ip-proto-17 19:17:04.993690 f4:90:ea:00:6d:e6 > 00:09:52:04:2d:b4, ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: ip-proto-17 19:17:06.993678 f4:90:ea:00:6d:e6 > 00:09:52:04:2d:b4, ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: ip-proto-17 19:17:10.993556 f4:90:ea:00:6d:e6 > 00:09:52:04:2d:b4, ethertype IPv4 (0x0800), length 76: 192.168.160.29 > 192.168.140.140: ip-proto-17

There are no entries for any blocked package on the firewall-log.

If I disable the Firewall (system_advanced_firewall.php -> Disable all packet filtering.) any call works like expected.

Does anyone have any idea howto fix this issue?

Thank you.

Kind regards Simon

SiJux avatar Apr 28 '22 04:04 SiJux

Thank you for creating an issue. Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

The easiest option to gain traction is to close this ticket and open a new one using one of our templates.

OPNsense-bot avatar Apr 28 '22 05:04 OPNsense-bot

This usually happens when not using "Static port" checkbox in outbound nat. I heard of some customers that in rare situation they have to set Rule optimization to "Conservative" in Firewall : Settings : Advanced

mimugmail avatar Apr 28 '22 06:04 mimugmail

Hi mimugmail,

thank you for your reply. After changing to "Conservative" now the phone rings but the connections breaks after 10 sec. Any further idea?

Thank you.

SiJux avatar May 03 '22 13:05 SiJux

@SiJux Just speaking from more of a VoIP knowledge perspective, compared to a firewall knowledge perspective, I would think that media breaking after 10 seconds is likely due to the ports as stated previously. If the firewall can't keep track of the state of the call with both signaling and media, usually after the signaling has completed, the firewall will assume the rest of that traffic is erroneous and won't be allowed through. At least that's what I've seen more often then not when working on VoIP projects (my job) and trying to work with various firewall teams in the past. Hopefully this helps shed a bit of light, or points you in the right direction at least!

mitchell-bumgarner avatar Oct 10 '22 16:10 mitchell-bumgarner

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.

OPNsense-bot avatar Oct 25 '22 03:10 OPNsense-bot