dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
4323

carp
Rejected
join:2002-10-30

carp to Bink

Member

to Bink

Re: Router ACL question

said by Bink:

This is bad advice—and a VERY poor substitute for a modern firewall.
Not if he only wanted to allow traffic back in that is in response to traffic initiated inside. Inspect makes sure those allowed back in, were not messed with. Depends on the level of protection desired and the risks you've accepted. Sometimes advanced protection will break things. So it's not as black and white as it's often portrayed.
Bink
Villains... knock off all that evil
join:2006-05-14
Colorado

1 edit

Bink

Member

It is black and white. This is akin to using firewall technology from the 1980s—and there are significant security flaws with this as all it does is look for an ACK or RST bits on a packet.

For example, while telnet and FTP work fine—it is well known they use clear text passwords. As such, I would never suggest they get used where security is a concern—and, in this case, you are suggesting someone use a known insecure method to secure his FIREWALL/network. Since a modern method of security and traffic inspection is readily available to him/built into his device, again, this is bad advice.

tomkb
Premium Member
join:2000-11-15
Tampa, FL

tomkb

Premium Member

I ran into a snag.

My linksys fax sip/ata device won't register with the external pbx although my sip phone registers just fine.

Sure enough, I put the allow ip any any back in there and the device registers just fine.

Anyone know what inspect statements I would need for this device?
HELLFIRE
MVM
join:2009-11-25

HELLFIRE to tomkb

MVM

to tomkb
I'd first figure out exactly what protocol(s) it's talking before turning
on anything. I don't know off the top of my head as I don't know what the
end device is or how it operates.

You may also want to watch the logging as a live stream goes thru the router
to see exactly what traffic is getting dropped and/or turn on debugging on
the inbound ACL.

Regards

tomkb
Premium Member
join:2000-11-15
Tampa, FL

tomkb

Premium Member

Well, I think I found the culprit, but it doesn't make any sense.

Jan 28 09:32:39: %SEC-6-IPACCESSLOGP: list 101 denied udp 27.166.204.3(5060) -> 74.21.119.213(5061), 257 packets

I do have 'ip inspect name myfw sip timeout 3600'
Bink
Villains... knock off all that evil
join:2006-05-14
Colorado

Bink

Member

See »www.cisco.com/en/US/docs ··· upp.html for details on working with the troublesome SIP protocol…

tomkb
Premium Member
join:2000-11-15
Tampa, FL

tomkb

Premium Member

Thanks for that, but I'm not sure it's the right answer.

In there example, they show the use of ip inspect for inbound traffic.

ip inspect name voip sip

interface FastEthernet 0/0
ip inspect voip in

I tried placing both in and out on the interface but no luck.

I think the best thing to do is just create an access list that allows open access from the network the pbx resides on.
HELLFIRE
MVM
join:2009-11-25

HELLFIRE to tomkb

MVM

to tomkb
Sure this wasn't the chunk you were missing tomkb?
quote:
!
!
access-list 100 permit udp host any eq 5060
access-list 100 permit udp host any eq 5060

access-list deny ip any any
From your logs, looks like somethings trying to initiate a connection to you on your port 5061.
Far as CBAC's concerned, it's unsolicited traffic from outside so it drops it. Try adding an
entry to your inbound ACL that permits on port 5060 and/or 5061 to see if that fixes it or not.
Just make sure it's not at the end of the ACL as they're processed top to bottom.

Regards

tomkb
Premium Member
join:2000-11-15
Tampa, FL

tomkb

Premium Member

said by HELLFIRE:

Sure this wasn't the chunk you were missing tomkb?
quote:
!
!
access-list 100 permit udp host any eq 5060
access-list 100 permit udp host any eq 5060

access-list deny ip any any
From your logs, looks like somethings trying to initiate a connection to you on your port 5061.
Far as CBAC's concerned, it's unsolicited traffic from outside so it drops it. Try adding an
entry to your inbound ACL that permits on port 5060 and/or 5061 to see if that fixes it or not.
Just make sure it's not at the end of the ACL as they're processed top to bottom.

Regards
No, I would only open port 5060 if the pbx was behind my router, it is not, just a sip phone and a fax device. The sip phone works ok, just not the fax device.
HELLFIRE
MVM
join:2009-11-25

HELLFIRE to tomkb

MVM

to tomkb
I'm only going off what your logs say tomkb as I don't know what the fax device
is or how it operates, and right now it looks like something's trying to talk
to you from their port 5060 to your 5061 (assuming it's traffic destined for the
fax) and ACL 101's blocking it.

A couple commands you can help you troubleshoot CBAC further is "show ip inspect
sessions" to see what's going outbound -- keep an eye for traffic from your fax
to see how it's communicating. Alternatively you can turn on the audit trail
in your inspect statements to see it.

Since you made so many changes to your config, reposting the latest one would
be a help as well.

Regards

tomkb
Premium Member
join:2000-11-15
Tampa, FL

tomkb

Premium Member

Well, I figured out what the problem was.

After much stress, it turned out the issue was an inspect sip statement on the pix/asa firewall where the remote pbx sits behind. It was not an issue with my cisco cbac router at home. After removal of the statement, the phone registered right away. For reference, here is the context of the statement on the pix. This is the default install for a pix running version 8.

policy-map type inspect dns migrated_dns_map_1
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect ftp
inspect h323 h225
inspect h323 ras
inspect http
inspect netbios
inspect rsh
inspect rtsp
inspect sip
inspect skinny
inspect sqlnet
inspect sunrpc
inspect tftp
inspect xdmcp
inspect dns migrated_dns_map_1
aryoba
MVM
join:2002-08-22

aryoba

MVM

said by tomkb:

Well, I figured out what the problem was.

After much stress, it turned out the issue was an inspect sip statement on the pix/asa firewall where the remote pbx sits behind. It was not an issue with my cisco cbac router at home. After removal of the statement, the phone registered right away.
Note that by removing the sip inspection, your sip traffic is no longer inspected (read: sip traffic is unprotected). You may want to tune the sip inspection by finding out which inspection parameter that cause the issue and go from there.

tomkb
Premium Member
join:2000-11-15
Tampa, FL

tomkb

Premium Member

I'm open to any suggestions on what to try and how to do it.
meta
join:2004-12-27
00000

1 edit

meta

Member

SIP is a complex protocol capable of many things. Anything from re-invites to re-establishment of data channels can occur and the ASA and FWSM simply dont handle things like that very well. Even ciscos own VOIP gurus ironclad advice is do not force voip through a firewall.

SIP & RTP should not go through firewalls (NAT especially). They make a product called a Session Border Controller. Either as a piece of software that runs on a server, a services module blade thats installed in a chassis, or stand alone appliance. These SBC's (voice firewalls) do not mangle VOIP. They provide a full L7 proxy for it.

The key issue with SIP is that the control traffic (SIP) must be analyzed at L7 for how the data session will be established. If SIP is not properly analyzed and correct conduits created for the data flow, you will end up with one-way audio, no audio, or dropped calls.

tomkb
Premium Member
join:2000-11-15
Tampa, FL

tomkb

Premium Member

said by meta:

SIP is a complex protocol capable of many things. Anything from re-invites to re-establishment of data channels can occur and the ASA and FWSM simply dont handle things like that very well. Even ciscos own VOIP gurus ironclad advice is do not force voip through a firewall.

SIP & RTP should not go through firewalls (NAT especially). They make a product called a Session Border Controller. Either as a piece of software that runs on a server, a services module blade thats installed in a chassis, or stand alone appliance. These SBC's (voice firewalls) do not mangle VOIP. They provide a full L7 proxy for it.

The key issue with SIP is that the control traffic (SIP) must be analyzed at L7 for how the data session will be established. If SIP is not properly analyzed and correct conduits created for the data flow, you will end up with one-way audio, no audio, or dropped calls.
Do you see this as a flaw in the protocol, ie could it have been created better?
meta
join:2004-12-27
00000

1 edit

meta

Member

The seperation of signaling and data connectivity isnt new. FTP among others can do the same thing. In SIPs case its deffinetly not a flaw. when you start talking about the complexity of call routing in environments that offer call bridging, call transfers, holding, IVRs, ACDs, etc. its by far SIPs strongest feature. It enables VOIP calls to take insane paths through different systems when answered by a machine, information is provided to the IVR, the data is included in SIP and a transfer or reinvite is issued to move it to an automated call distribution system to the righr agent in a call center while providing the information they entered into the IVR 3 steps prior, the agent can bridge on other people and invite them to the call, and all with the extensibility to include voice and video of any type present and future makes it tremendously flexible.

That flexibility unfortunately introduces complexity. Complexity is the thing to avoid in any system, large or small. It becomes difficult to support and almost impossible to interoperate with. Instances like this where an inline device needs to understand the protocol almost completely to interact with it require fairly complex logic, and its not a simple stare and compare rule for a router or firewall to look at. Thats why we have very complex voip soft switches, session border controllers, voice gateways, etc. to handle all this call processing and routing (and pstn interconnectivity).