Blocking SIP Traffic from Specific Countries

[RobM]

I'm familiar with blocking traffic from specific countries using the Firewall application. My understanding is that SIP traffic is generally bypassed using a bypass rule to prevent the introduction of latency during the processing of SIP traffic. Is it possible to setup a configuration where 1) SIP from certain countries is blocked and 2) SIP from other countries is bypassed to not introduce unnecessary latency?

[gravenscroft]

Is it possible to setup a configuration where 1) SIP from certain countries is blocked and 2) SIP from other countries is bypassed to not introduce unnecessary latency?

In short, no.

In long: Bypass Rules are often necessary for VoIP-related traffic, as it is extremely fragile and usually doesn't survive the transition to the UVM and back. The issue here is that Bypass Rules completely bypass the UVM, which is where the Firewall app operates. Bypassed traffic cannot be subject to Firewall rules and, by association, any traffic that is to be processed by the Firewall app cannot be bypassed.

The geoip information used by the Firewall app only exists at layer 7, inside the UVM; the layer-3 settings found in Config (including Bypass Rules) cannot access layer-7 information.

It is possible to create a 'block SIP from X country' rule in the Firewall app, but of course the traffic has to be processed by the Firewall app for that rule to take effect. Even if you create a granular rule that won't affect countries you would like to allow to create SIP connections, the traffic still has to hit the Firewall app (and thus the UVM), which introduces the 'VoIP traffic won't survive the UVM' problem.

The closest thing you could do would be to use Filter Rules instead of the Firewall application. Filter Rules operate at layer 3, so they're not subject to Bypass Rules, but the problem is their criteria are limited to layer-3 attributes and don't include geoip details. You'd have to be able to locate IP address blocks specific to those countries, which isn't always immediately available information.

[RobM]

In short, no.

In long: Bypass Rules are often necessary for VoIP-related traffic, as it is extremely fragile and usually doesn't survive the transition to the UVM and back. The issue here is that Bypass Rules completely bypass the UVM, which is where the Firewall app operates. Bypassed traffic cannot be subject to Firewall rules and, by association, any traffic that is to be processed by the Firewall app cannot be bypassed.

The geoip information used by the Firewall app only exists at layer 7, inside the UVM; the layer-3 settings found in Config (including Bypass Rules) cannot access layer-7 information.

It is possible to create a 'block SIP from X country' rule in the Firewall app, but of course the traffic has to be processed by the Firewall app for that rule to take effect. Even if you create a granular rule that won't affect countries you would like to allow to create SIP connections, the traffic still has to hit the Firewall app (and thus the UVM), which introduces the 'VoIP traffic won't survive the UVM' problem.

The closest thing you could do would be to use Filter Rules instead of the Firewall application. Filter Rules operate at layer 3, so they're not subject to Bypass Rules, but the problem is their criteria are limited to layer-3 attributes and don't include geoip details. You'd have to be able to locate IP address blocks specific to those countries, which isn't always immediately available information.

Great explanation! This is exactly what I expected based on my understanding of how bypass rules and layer 7 apps interact. I was hoping for a solution that I didn't really think was possible but wanted to make sure I didn't overlook anything.

The good news is that I was able to track most of the offending traffic to one ISP (and a couple subsidiaries) in a number of different countries (including my own). It took a while, but I was able to identify blocks of IPs which I blocked with filter rules. I had to create 17 different rules to address different blocks (which ranged in size anywhere from /16 to /24), but at the end I've essentially blocked all traffic from the offending ISP with minimal impact on traffic from other ISPs in those regions. It seems the particular ISP either does very little monitoring of what is happening on their networks or they simply don't care so they were the source of nearly all malicious VoIP traffic reaching my PBX's firewall. I've now shifted the vast majority of that work from my PBX to Untangle to prevent the traffic from entering my network at all.

[gravenscroft]

It seems the particular ISP either does very little monitoring of what is happening on their networks or they simply don't care so they were the source of nearly all malicious VoIP traffic reaching my PBX's firewall. I've now shifted the vast majority of that work from my PBX to Untangle to prevent the traffic from entering my network at all.

I truly believe that most ISPs don't care at all. Their position is effectively 'we just build the road; it's your call how you drive on it'. In any case, I'm glad to be of some assistance!