I have a customer that I had to go onsite and prove that the firewall was not blocking SIP traffic. The phone guy there was saying that the firewall was blocking the SIP traffic going out to the carrier. Now, I know it wasn't the firewall that was the problem. After all, I configured it. But, as you know, the network guy has to prove everything. So, I went onsite and did a packet capture. The internal IP address of 10.11.1.250 is actually hitting the inside interface of the ASA. Here is how I know:
PACKETS COMING INTO THE INSIDE THE INTERFACE:
ASA(config)# access-list 189 permit ip host 10.11.1.250 host 50.50.50.38
ASA(config)# capture capin interface inside access-list 189
ASA(config)# show capture capin
...
41: 16:20:17.844484 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
42: 16:20:22.025969 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
43: 16:20:50.807422 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
44: 16:20:51.367931 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
45: 16:20:52.463721 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
46: 16:20:54.561479 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
47: 16:20:58.749808 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
48: 16:21:02.904631 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
49: 16:21:07.055569 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
50: 16:21:11.196935 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
51: 16:21:15.346310 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
52: 16:21:19.507923 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
53: 16:21:23.668056 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
54: 16:21:52.539492 10.11.1.250.5060 > 50.50.50.38.5060: udp 394
Now, I want to see the traffic being sent out the ASA on the outside interface. I mean, I need to know that the traffic is actually getting THROUGH the firewall, right? Looks like the NAT'ed IP address of 40.40.40.250 is making it out to the destination of IP 50.50.50.38:5060. Lets see below:
PACKETS GOING OUT THE OUTSIDE INTERFACE:
ASA(config)# access-list 191 permit ip any host 50.50.50.38
ASA(config)# capture capin interface outside access-list 191
ASA(config)# sh capture capin
26 packets captured
1: 17:08:02.706521 40.40.40.194 > 50.50.50.38: icmp: echo request
2: 17:08:03.706506 40.40.40.194 > 50.50.50.38: icmp: echo request
3: 17:08:04.706659 40.40.40.194 > 50.50.50.38: icmp: echo request
4: 17:08:04.881820 40.40.40.250.5060 > 50.50.50.38.5060: udp 394
5: 17:08:05.440544 40.40.40.250.5060 > 50.50.50.38.5060: udp 394
6: 17:08:05.706765 40.40.40.194 > 50.50.50.38: icmp: echo request
7: 17:08:06.528354 40.40.40.250.5060 > 50.50.50.38.5060: udp 394
8: 17:08:06.707818 40.40.40.194 > 50.50.50.38: icmp: echo request
9: 17:08:07.707894 40.40.40.194 > 50.50.50.38: icmp: echo request
10: 17:08:08.642926 40.40.40.250.5060 > 50.50.50.38.5060: udp 394
11: 17:08:08.707894 40.40.40.194 > 50.50.50.38: icmp: echo request
12: 17:08:09.709100 40.40.40.194 > 50.50.50.38: icmp: echo request
13: 17:08:10.709130 40.40.40.194 > 50.50.50.38: icmp: echo request
14: 17:08:11.709222 40.40.40.194 > 50.50.50.38: icmp: echo request
15: 17:08:12.710305 40.40.40.194 > 50.50.50.38: icmp: echo request
16: 17:08:12.794285 40.40.40.250.5060 > 50.50.50.38.5060: udp 394
17: 17:08:13.710580 40.40.40.194 > 50.50.50.38: icmp: echo request
18: 17:08:14.710458 40.40.40.194 > 50.50.50.38: icmp: echo request
19: 17:08:15.711556 40.40.40.194 > 50.50.50.38: icmp: echo request
20: 17:08:16.711663 40.40.40.194 > 50.50.50.38: icmp: echo request
21: 17:08:16.926755 40.40.40.250.5060 > 50.50.50.38.5060: udp 394
22: 17:08:17.712792 40.40.40.194 > 50.50.50.38: icmp: echo request
23: 17:08:18.713876 40.40.40.194 > 50.50.50.38: icmp: echo request
24: 17:08:19.714028 40.40.40.194 > 50.50.50.38: icmp: echo request
25: 17:08:20.714043 40.40.40.194 > 50.50.50.38: icmp: echo request
26: 17:08:21.085521 40.40.40.250.5060 > 50.50.50.38.5060: udp 394
26 packets shown
Looks like it is being NAT'ed correctly and also being sent out to the appropriate external IP address. Looks like the firewall is OK.
"But, as you know, the network guy has to prove everything." Now that is one accurate statement!! Whenever there is an application issue, the network is always blamed first. So then we have to prove it isn't. Can't believe how much time I spend proving the problem is higher up on the protocol stack. However, it does keep us employed!!
ReplyDeleteYeah, you are correct for sure Brad. As frustrating as it can be, it may actually make us better at what we do. I tell myself that anyway.
Delete