Re: Streaming Video With Stateful Inspection

Daniel Mckibbin · ‎04-17-2011

I can't for the life of me get streaming video to work with stateful inspection. It looks like youtube is only using ports 80 and 443 for communication and I have those ports opened. Does stateful inspection inspect source or destination IP addresses? I'm assuming destination. I'll list the relevant portion of my config below. I'm not sure what's preventing the video to stream. I would also like similar flash/divx type video to work through the firewall...

Extended IP access list FW-STATEFUL
    10 permit udp host 207.200.81.113 any eq ntp (36 matches)
    20 permit udp host 69.25.96.13 any eq ntp (36 matches)
    30 permit udp host 64.146.116.22 any eq ntp
    40 permit udp host 64.147.116.229 any eq ntp (36 matches)
    50 permit udp host 216.171.124.36 any eq ntp (36 matches)
    60 permit icmp 208.69.250.0 0.0.0.255 any
    70 permit udp any any eq bootpc (45 matches)
    80 deny ip any any log (328 matches)

ip inspect name FW-INSPECT http
ip inspect name FW-INSPECT https
ip inspect name FW-INSPECT udp
ip inspect name FW-INSPECT tcp
ip inspect name FW-INSPECT dns
ip inspect name FW-INSPECT ntp
ip inspect name FW-INSPECT icmp

interface FastEthernet2/0
description Cox Connection
ip ddns update hostname danielmckibbin.dyndns.org
ip ddns update ddns_update
ip address dhcp
ip access-group FW-STATEFUL in
ip flow ingress
ip flow egress
ip nbar protocol-discovery
ip nat outside
ip inspect FW-INSPECT out
ip virtual-reassembly max-reassemblies 24
duplex auto
speed auto
no cdp enable
end

When video hangs on the loading screen the deny any any counter in show access-lists increments. Here are a few log entries:

LOGP: list FW-STATEFUL denied tcp 208.93.141.80(80) -> 68.98.36.58(60726), 1 packet
Apr 17 2011 21:03:09 MST: %SEC-6-IPACCESSLOGP: list FW-STATEFUL denied tcp 96.6.224.170(443) -> 68.98.36.58(60669), 1 packet
Apr 17 2011 21:03:12 MST: %SEC-6-IPACCESSLOGP: list FW-STATEFUL denied tcp 96.6.224.170(443) -> 68.98.36.58(60672), 1 packet
Apr 17 2011 21:03:32 MST: %SEC-6-IPACCESSLOGP: list FW-STATEFUL denied tcp 96.6.224.170(443) -> 68.98.36.58(60670), 1 packet
Apr 17 2011 21:03:34 MST: %SEC-6-IPACCESSLOGP: list FW-STATEFUL denied tcp 184.51.30.64(443) -> 68.98.36.58(60649), 1 packet
Internet_Router#

Netstat from the comp with acl and stateful inspection removed from interface:

Can not obtain ownership information
TCP    172.16.1.35:60727      172.16.2.1:22          ESTABLISHED
[ttermpro.exe]
TCP    172.16.1.35:60732      74.125.113.103:80      TIME_WAIT
TCP    172.16.1.35:60733      74.125.113.103:80      TIME_WAIT
TCP    172.16.1.35:60734      74.125.113.103:80      TIME_WAIT
TCP    172.16.1.35:60749      74.125.224.164:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60750      74.125.47.102:80       ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60751      74.125.224.175:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60752      74.125.224.201:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60753      173.194.26.86:80       ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60754      74.125.224.196:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60755      74.125.224.196:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60756      74.125.224.171:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60757      74.125.224.170:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60758      74.125.224.170:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60759      74.125.224.165:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60760      74.125.224.219:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60761      74.125.113.103:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60762      64.208.159.18:80       ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60763      74.125.224.219:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60764      74.125.224.219:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60765      74.125.224.219:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60766      74.125.224.218:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60767      74.125.224.188:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60768      74.125.224.188:80      ESTABLISHED
[firefox.exe]
TCP    172.16.1.35:60769      184.51.30.64:443       ESTABLISHED

Thanks in advance!

mirober2 · ‎04-18-2011

Hi Daniel,

Have you tried testing without HTTP and HTTPS inspections enabled? This can tell the router to do RFC protocol checks and enforce TCP packet order, so packets can be dropped for these reasons. Try removing them and testing again:

no ip inspect name FW-INSPECT http
no ip inspect name FW-INSPECT https

The TCP inspection is enough to open pinholes for the return traffic to come back into your network.

Hope that helps.

-Mike

Daniel Mckibbin · ‎04-19-2011

Mike,

You know, I was thinking the same thing, and it worked. I guess when you specify a transport layer protocol you don't have to specify the more specific protocols. I didn't think it would cause any problems though. I still need to troubleshoot why Dynamic DNS responses are being blocked by the incoming access-list. I believe it's because packet originating from the router itself seem to be blocked. DNS resolution on the router ICMP pings sourced from the router etc.., but within the local network it works no problem. I wonder how I can get the router to inspect packets originated by itself, that way ddns requests don't get blocked on the way back. I tried adding an entry to allow ICMP on the way back because I saw through logging that those IP's were being blocked, maybe if I create a permit entry on the inbound acl for dyndns allowing HTTP since HTTP is used with the requests.

mirober2 · ‎04-20-2011

Hi Daniel,

Give this a try:

ip inspect name FW-INSPECT udp router-traffic

This will apply the inspection engine to traffic sourced from the router, and thus open pinholes for the return traffic.

Hope that helps.

-Mike