Announcement

Collapse
No announcement yet.

IOS and CBAC (870 Series) - Traffic generated by router

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • IOS and CBAC (870 Series) - Traffic generated by router

    Hi All,

    I'm configuring CBAC ("Classic Firewall") for the first time. I'm trying it under 12.4(15)T8 on an 877, although I don't believe this to be specific to either IOS or router model, rather it's a mistake on my part!

    Whilst all works fine for the clients behind the router, traffic generated by the router itself seems to be ignored by CBAC's inspect rules and is consequently dropped by the ACL on the external interface.

    I've created an inspection set:

    Code:
    ip inspect tcp idle-time 300
    ip inspect tcp synwait-time 10
    ip inspect name OUTBOUND tcp
    ip inspect name OUTBOUND udp
    ip inspect name OUTBOUND ftp
    ip inspect name OUTBOUND icmp
    ip inspect name OUTBOUND bittorrent
    ip inspect name OUTBOUND ssh
    ip inspect name OUTBOUND smtp
    ip inspect name OUTBOUND https
    ip inspect name OUTBOUND dns
    ip inspect name OUTBOUND ntp
    And applied it to the dialer interface:

    Code:
    interface Dialer0
     description <snip>
     ip ddns update hostname <snip>
     ip ddns update dyndns
     ip address negotiated
     ip access-group 101 in
     no ip redirects
     no ip unreachables
     no ip proxy-arp
     ip nat outside
     ip inspect OUTBOUND out
     ip virtual-reassembly
     encapsulation ppp
     no ip mroute-cache
     dialer pool 1
     dialer-group 1
     random-detect
     no cdp enable
     ppp authentication chap callin
     ppp chap hostname <snip>
     ppp chap password 7 <snip>
    end
    And that works great for all the NAT'd clients on the inside. It's let me cut my ACL 101 right down (basically just HTTPS in for SSLVPN web clients).

    However, any traffic the router generates is caught by ACL 101 and dropped. This includes:
    • DNS Lookups
    • ICMP
    • Traffic from SSLVPN clients destined outbound


    I had assumed that given this traffic goes out the Dialer0 interface to which I've applied the outbound inspection CBAC would pick it up and allow in replies. A packet debug shows it is leaving on Dialer0 - here's me pinging Google from the router and it being caught by ACL 101:

    Code:
    000300: Feb  4 12:27:06: IP: tableid=0, s=<my ip> (local), d=216.239.59.104 (Dialer0), routed via FIB
    000301: Feb  4 12:27:06: IP: s=<my ip> (local), d=216.239.59.104 (Dialer0), len 100, sending
    000302: Feb  4 12:27:06: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 216.239.59.104 -> <my ip> (0/0), 1 packet
    000303: Feb  4 12:27:06: IP: s=216.239.59.104 (Dialer0), d=<my ip>, len 84, access denied
    So what do I do to get CBAC to start inspecting (and allowing replies to!) traffic from the router?

    Any help much appreciated - let me know if you've any questions!

    Thanks,

    Dan

  • #2
    Re: IOS and CBAC (870 Series) - Traffic generated by router

    Hahaha, well in the process of writing the post and having to word my problem in a way for others to understand I ended up working out better search terms...

    Googling for "CBAC source traffic router" gives this handy document:

    http://www.cisco.com/en/US/docs/ios/...tr_gen_trf.pdf

    If you jump to page 4 you find you just need to add "router-traffic" to the end of any inspection that you want to match router generated traffic. So, my inspection is now:

    Code:
    ip inspect tcp idle-time 300
    ip inspect tcp synwait-time 10
    ip inspect name OUTBOUND tcp router-traffic
    ip inspect name OUTBOUND udp router-traffic
    ip inspect name OUTBOUND ftp
    ip inspect name OUTBOUND icmp router-traffic
    ip inspect name OUTBOUND bittorrent
    ip inspect name OUTBOUND ssh
    ip inspect name OUTBOUND smtp
    ip inspect name OUTBOUND https
    ip inspect name OUTBOUND dns
    ip inspect name OUTBOUND ntp
    And it all works just fine...hope this helps someone else Googling for the same problem!

    (Not sure why the inspection on the outbound interface doesn't match anyway, but apparently this is by design)

    Comment

    Working...
    X