Update: Inspect router-generated traffic

In my previous post, I've described how you can get a very clean configuration with no holes in your Internet-facing access-list if you have IOS release that supports inspection of router-generated traffic. As it turns out, my solution was not complete - you could not ping from the router. On top of inspecting UDP and TCP traffic (as is usually done), you also have to inspect ICMP traffic that the router uses for pings.

Furthermore, if you use any protocols that have separate control and data sessions (for example, FTP, H.323 or SIP), you have to list them before tcp or udp keywords, otherwise their control streams will not be inspected and there will be no provision for data sessions.
ip inspect name Internet ftp
ip inspect name Internet h.323 router-traffic
ip inspect name Internet sip router-traffic
ip inspect name Internet tcp router-traffic
ip inspect name Internet udp router-traffic
ip inspect name Internet icmp router-traffic
!
interface FastEthernet0/0
ip access-group Internet in
ip inspect Internet out
!
ip access-list extended Internet
deny ip any any

12 comments:

  1. Hello -

    Nice work...Inverse mask was the only option when configuring network statements under OSFP, both options were not always available. I'm not real sure which IOS version Cisco introduced the new option.

    Just thought to add the comments in case people do run into older versions.

    Keep up the good work.
  2. The previous comment probably relates to this post.
  3. Thanks for this article Ivan. Always knew there had to be a better way than using PBR tied to a Loopback to force CBAC inspection of the router originated traffic.
  4. Hi,

    thanks for nice post, but i have two question.

    1) Is there any chance to inspect L2L IPsec tunell which originate at the router. I know that i can inspect UDP by using "ip inspect name OUTSIDE-ROUTER udp router-traffic" but what about ESP?

    2) How can i firewalling traffic which is routed to IPsec VPN tunell?

    Thanks for reply.
  5. You cannot inspect ESP traffic, you have to allow it explicitely in the inbound access list (access-list Internet in my example).

    As for inspecting IPSec traffic: if you're using crypto maps on the public interface, the traffic will have to pass the inspection and inbound access list anyway; if you're using a protected tunnel interface, you can configure access list and ip inspect on the tunnel interface.
  6. Hi there!
    And thanks for all the info!

    I found some problem with ip inspect and router originated tftp traffic.

    I start a copy ru tftp: and I see that the CBAC opens that connection. But the tftp server does not respond from the same server port! thus, the ip inspect does not work here.

    Example packets:
    router: 10.0.0.1
    tftp server: 10.0.0.2

    udp 10.0.0.1:5423 -> 10.0.0.2:69
    udp 10.0.0.2:3658 -> 10.0.0.1:5423

    See that? the tftp server response came from another port!
    Any ideas how to fix this?

    Thanks!
  7. This is how TFTP works. You would need "ip inspect name X tftp router-traffic" but that does not exist.
  8. Thanks Ivan.
    Strange thing... cisco didn't came up with a router-traffic option for tftp protocol inspection.
  9. Hi, I also encountered a "tftp" similar problem when router was DNS server for the internal network. Ideal would have been a "ip inspect name X dns router-traffic" but it does not exist either. Fortunately, in this case, "ip inspect name X udp router-traffic" is enough.
  10. Marious -- Thank you so much for pointing this out!
  11. Ivan I can't thank you enough for this article - I was going spare trying to configure for a small office WAN. I have a problem though when rebooting my Cisco 867 router. Essentially all inside NAT translations will not work until I do the following on the outside interface GigabitEthernet2

    no ip access-group Internet in
    ip access-group Internet in

    It's like there is an ordering problem only resolved by deleting and reapplying the access-group. My interface definition looks like this - I've checked the running-config and the boot up config and the order is identical:

    ip inspect name Internet-out icmp router-traffic
    ip inspect name Internet-out tcp router-traffic
    ip inspect name Internet-out udp router-traffic

    interface GigabitEthernet2
    description PrimaryWANDesc_iiNet NBN
    ip address dhcp
    ip access-group Internet in
    no ip unreachables
    ip inspect Internet-out out
    ip nat outside
    ip virtual-reassembly in
    duplex auto
    speed auto
    no cdp enable
    !

    Any pointers? Is this some type of known bug?



    Replies
    1. Looks like a bug to me. Known one? I wouldn't know. Anyway, here's how you might implement a workaround:

      http://blog.ipspace.net/2007/04/fix-router-configuration-after-reload.html
Add comment
Sidebar