carpRejected join:2002-10-30 |
to Bink
Re: Router ACL questionsaid by Bink:This is bad adviceand 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. |
|
BinkVillains... knock off all that evil join:2006-05-14 Colorado 1 edit |
Bink
Member
2010-Jan-27 2:27 pm
It is black and white. This is akin to using firewall technology from the 1980sand 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 fineit is well known they use clear text passwords. As such, I would never suggest they get used where security is a concernand, 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
2010-Jan-27 4:20 pm
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? |
|
|
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
2010-Jan-28 9:38 am
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' |
|
BinkVillains... knock off all that evil join:2006-05-14 Colorado |
Bink
Member
2010-Jan-28 10:20 am
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
2010-Jan-28 12:22 pm
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. |
|
|
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
2010-Jan-30 3:18 pm
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. |
|
|
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
2010-Feb-9 9:17 pm
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
2010-Feb-10 9:17 am
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
2010-Feb-10 11:00 am
I'm open to any suggestions on what to try and how to do it. |
|
1 edit |
meta
Member
2010-Feb-10 3:04 pm
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
2010-Feb-11 5:04 pm
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? |
|
1 edit |
meta
Member
2010-Feb-11 5:21 pm
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). |
|