Some of the newer versions of IOS support stateful inspection filtering, and can also do it with IPv6. I'm running a Cisco 881 (IP advanced services) and IOS 12.4(24)T2. Just thought I would share this, as I thought it was important to secure my inside network and this device happened to do the job. To clarify, I am terminating a v6 tunnel on this device, and it is directly connected to my ISP with a v4 DHCP address on the outside.
First we deny traffic INBOUND on the tunnel interface but allow some normal icmp traffic first:
ipv6 access-list INBOUND
permit icmp any any nd-na
permit icmp any any nd-ns
permit icmp any any echo-reply
permit icmp any any hop-limit
permit icmp any any time-exceeded
deny ipv6 any any
To apply it to the tunnel0 interface we just do this:
interface Tunnel0
ipv6 traffic-filter INBOUND in
Now we define the types of traffic we want to create stateful inspections for:
ipv6 inspect name ipv6-out icmp
ipv6 inspect name ipv6-out tcp
ipv6 inspect name ipv6-out udp
ipv6 inspect name ipv6-out ftp
And we apply it to the inside interface where the traffic will be heading out towards the tunnel:
interface Vlan1
ipv6 inspect ipv6-out in
Now only my permitted icmp v6 traffic from the first ACL is permitted in, and return traffic through the tunnel that was inspected on the way out.
To verify the stateful sessions, you can do the following:
show ipv6 inspect sessions
Works great mikea!
I am seeing some denies in the logs for icmpv6 though. You think these are normal?
Also wanted to add that I've added two extra lines (permit TCP & UDP) for any hosts to my specific LAN machine's IP for bittorrent traffic. And yes I can see a couple of IPv6 peers in utorrent because of it. :) Here are the two lines:
permit tcp any host 2001:x:x:x:x eq <bittorrent port>
permit udp any host 2001:x:x:x:x eq <bittorrent port>
Lobo
Quote from: lobotiger on April 09, 2010, 08:20:08 PM
I am seeing some denies in the logs for icmpv6 though. You think these are normal?
I guess it depends what type of icmpv6 it is that is being denied. Can you post an example?
BTW, I haven't played with IPv6 on IOS all that much. Does IOS IPv6 ACLs support the Cisco IPv4 style wildcard masks for IPv6, or is it only prefix length based? From what I've seen so far, it only looks like they'll do prefix length, which is kind of a shame since there's some instances where wildcards are very nice. And it's not like it'd be costly CPU or hardware wise to implement, since they're a bitwise AND mask followed by a compare.
No, it doesn't appear that any types of wildcard masks are available. Only prefix/length.
These are the only options available for doing a permit in an ipv6 ACL:
router(config-ipv6-acl)#permit ipv6 ?
X:X:X:X::X/<0-128> IPv6 source prefix x:x::y/<z>
any Any source prefix
host A single source host
Quote from: mikea on April 14, 2010, 11:48:23 AM
No, it doesn't appear that any types of wildcard masks are available. Only prefix/length.
These are the only options available for doing a permit in an ipv6 ACL:
router(config-ipv6-acl)#permit ipv6 ?
X:X:X:X::X/<0-128> IPv6 source prefix x:x::y/<z>
any Any source prefix
host A single source host
That's what I've seen too, although I haven't played with IOS 15 much. Just about everything you'd want to do can be done with prefix length notation, but not everything.
Hi Jim,
Can you give an example where a prefix length would't cut it?
(Genuinine question - I'm trying to learn this stuff and the 'quirks' often help!)
Mathew
Quote from: NewtonNet on April 17, 2010, 11:25:31 AM
Hi Jim,
Can you give an example where a prefix length would't cut it?
(Genuinine question - I'm trying to learn this stuff and the 'quirks' often help!)
Mathew
Lets say you had a bunch of subnets with critical servers you wanted to protect from the outside (or whatever) on each subnet which lived in the first 64 IIDs (0-63) of each net. With prefix lengths, you'd need a separate ACL for each subnet like this:
- deny any 2001:db8:1234::/122
- deny any 2001:db8:1234:1::/122
- deny any 2001:db8:1234:2::/122
- deny any 2001:db8:1234:3::/122
- deny any 2001:db8:1234:4::/122
- deny any 2001:db8:1234:5::/122
- deny any 2001:db8:1234:6::/122
- deny any 2001:db8:1234:7::/122
With Cisco style wildcards (in the format that I
think they'd look like for ipv6), you could match those addresses with a single ACL:
- deny any 2001:db8:1234:: ::7:0:0:0:3f
(0s are "fixed" bits, 1s are "wild", essentially an inverted bitwise AND mask applied to the IPv6 addr in the packet, then compared to the ACL address on the left. Matches any address in the range 2001:db8:1234:0-7:0:0:0:0-63)
Or lets say you wanted to block packets to your tunnel network which would result in a ping-pong forwarding loop, and you were running a tunnel server which served a /48 worth of /64 tunnels. In each tunnel, the only valid IPs are :1 and :2 for the local and remote ends. Packets to any other address would result in a forwarding loop ping-ponging between the local and remote end until the hop limit was reached. To prevent this from happening, you could do this with outgoing prefix length based traffic filters (on the tunnel server end):
- permit any 2001:db8:1234::2/128
- deny any 2001:db8:1234::/64
- permit any 2001:db8:1234:1::2/128
- deny any 2001:db8:1234:1::/64
- permit any 2001:db8:1234:2::2/128
- deny any 2001:db8:1234:2::/64
- permit any 2001:db8:1234:3::2/128
- deny any 2001:db8:1234:3::/64
- ...
- permit any 2001:db8:1234:ffff::2/128
- deny any 2001:db8:1234:ffff::/64
- permit any any
(a LOT of ACLs)
With wildcards this could be reduced to a pair of ACLs which would cover a whole /48 worth of /64s (plus the permit any):
- permit any 2001:db8:1234::2 ::ffff:0:0:0:0
- deny any 2001:db8:1234::/48
- (OR "deny any 2001:db8:1234:: ::ffff:ffff:ffff:ffff:ffff " if mixing/matching of ACL syntax isn't allowed. I don't see why it wouldn't, since the presence of a /XX would indicate a prefix length, otherwise it's a wildcard style line.)
- permit any any
That would only allow traffic to the :2 IID on every /64 that is part of the 2001:db8:1234::/48. It'd be applied to outgoing traffic on each tunnel interface.
The power of the wildcards is that it allows you to simultaneously match different parts of the address bits, where prefix lengths restrict one to only contiguous matches from the left-hand-side of the address.
It wouldn't require any more computational power than the prefix length compares, since it's just bitwise AND and compare. Which is probably why Cisco used that from the get-go (that and since subnet masks weren't mandated to be contiguous). I suspect that the prefix length matching works the same way, just storing an AND mask matching the prefix length. This is how it'd work (in C like pseudo-code):
uint128 masked_addr, packet_addr, acl_mask, acl_addr; // 128 bit valuesmasked_addr = (packet_addr & acl_mask); // bitwise AND packet address against inverted wildcard mask from ACL // compare masked address and address from ACLif(masked_addr == acl_addr) { // match code } else { // don't match code }(the wildcard masks would be stored inverted with something like
acl_struct->acl_mask = ~acl_wildmask;)
So very simple/basic as far as CPU cycles or ASIC implementation. Only reason I mention this is 'cause some people seemed to think that this would be a big CPU burden or something, when this (educated guess) how Cisco and everyone else have implemented ACLs from the beginning.
-Jim
Thanks Jim for the comprehensive reply - very useful.
So it basically boils down to representing discontiguous address ranges in one go rather than individually?
From the scenerios you describe it does make you wonder why Cisco have taken a backwards step in this regard, particularly if there's performance hit as you posit? Or do think it is more a case of the (im)maturity of IPv6 support and that this functionality will come one day?
Cheers,
Mathew
Quote from: NewtonNet on April 18, 2010, 01:39:50 AM
Thanks Jim for the comprehensive reply - very useful.
So it basically boils down to representing discontiguous address ranges in one go rather than individually?
Pretty much. It just gives flexibility in that you can compare and "mask" bits in various positions, and if it works in the code and ASICs as I presume it does, it would be more efficient seeing that you'd need fewer ACLs do to the same thing in certain cases.
QuoteFrom the scenerios you describe it does make you wonder why Cisco have taken a backwards step in this regard, particularly if there's performance hit as you posit? Or do think it is more a case of the (im)maturity of IPv6 support and that this functionality will come one day?
Cheers,
Mathew
There could be a lot of reasons for them to do the prefix length only thing. It could be that the ASICs or code aren't implemented the way I think they are (perhaps they use TCAM or something). Or it could just be to make things more consistent (since the pref-length thing is used for many other things, routes, etc). Or maybe just fashion (netmasks and wildmasks are "old hat" and CIDR/pref length notation is the "new" way). Or maybe they figured that people wouldn't need to do the sorts of matching in my examples often enough to require wildcards. After all, prefix lengths cover typical ACL matches just fine.
Note that the prefix length vs. wildcard mask itself shouldn't directly cause any sort of performance hit, since as I mentioned, the prefix length matching code could be implemented the same way, just generating an AND mask from the address/preflength pair (at configuration time, not run time) and doing the comparison the same way. A performance hit would only arise from a case of requiring way more ACLs for a particular sort of match (as in my examples) than the wildcard ACL would require.
IMHO, since there are so many bits in an IPv6 address, it would seem to
me that based on the examples I give, plus others I probably haven't thought of yet, that having the ability to do both wildcard and/or preflength style ACL clauses would be a good thing. But there may be technical reasons why they may prefer the latter.
I have no idea whether we'll see the return of wildcards or not. My guess, if people find the need to do those sorts of comparisons then we'll see their return, or some other mechanism such as chaining ACLs based matching, or doing multiple preflength compares in a single ACL using logical operators, or something like that). It'd probably depend on what is closest to the underlying hardware. But to me, not being a router hardware engineer, a simple bitwise AND followed by a compare would seem to be the fastest, since these are super-basic functions of any CPU or ASIC. But as I said, I'm not a EE type working on router ASICs/hardware, so my presumptions could be way off. :P
Quote from: mikea on April 12, 2010, 04:59:13 PM
Quote from: lobotiger on April 09, 2010, 08:20:08 PM
I am seeing some denies in the logs for icmpv6 though. You think these are normal?
I guess it depends what type of icmpv6 it is that is being denied. Can you post an example?
Here is what I'm seeing:
2034473: Apr 18 08:17:42.929 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:4137:9E74:14C1:3475:B951:F50B -> 2001:470:B081::2 (128/0), 1 packet
2034484: Apr 18 08:17:54.085 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:4137:9E74:2C57:4A:BA3B:75D9 -> 2001:470:B081::2 (128/0), 1 packet
2034485: Apr 18 08:18:00.553 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:4137:9E76:1477:32EB:86A7:5F2F -> 2001:470:B081::2 (128/0), 1 packet
2034486: Apr 18 08:18:02.029 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:CF2E:3096:30AB:162B:8683:4697 -> 2001:470:B081::2 (128/0), 1 packet
2034487: Apr 18 08:18:02.805 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:4137:9E76:18EC:90B:9C77:AF36 -> 2001:470:B081::2 (128/0), 1 packet
2034489: Apr 18 08:18:13.625 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:4137:9E76:101C:2B48:2C3B:E86C -> 2001:470:B081::2 (128/0), 1 packet
2034490: Apr 18 08:18:20.366 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:4137:9E76:2806:20C9:2314:E4F7 -> 2001:470:B081::2 (128/0), 1 packet
2034494: Apr 18 08:19:02.823 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:CF2E:3096:38BE:2C18:C552:4A78 -> 2001:470:B081::2 (128/0), 1 packet
2034496: Apr 18 08:19:19.687 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:5EF5:73BA:837:371B:A83D:3C19 -> 2001:470:B081::2 (128/0), 1 packet
2034498: Apr 18 08:19:51.488 EDT: %IPV6-6-ACCESSLOGDP: list IPV6_EXTERNAL_ACL/80 denied icmpv6 2001:0:5EF5:73BA:1827:13BC:A089:AABB -> 2001:470:B081::2 (128/0), 1 packetLoboTiger
Those are echo requests (pings). You deny them in your INBOUND ACL (or more accurately, don't permit them).
Yes, I originally had left out a permit for echo requests and added it after I had posted the original ACL above.
Quote from: mikea on April 18, 2010, 09:43:38 AM
Yes, I originally had left out a permit for echo requests and added it after I had posted the original ACL above.
Hrm. Well it shouldn't be generating those log entries then.
I just noticed that all the source IPv6 addresses are from Teredo clients. Not sure why this would make a difference unless Cisco does some sort of "magic" with Teredo addresses (treats them differently for whatever reason). Perhaps their IPv4 Teredo packets that the router is logging as IPv6?
Quote from: jimb on April 18, 2010, 03:35:07 PM
Hrm. Well it shouldn't be generating those log entries then.
I was saying that I didn't include the permit echo requests when I originally posted this thread and it sounded like lobotiger used that ACL. So lobotiger still may not have a permit for echo requests. So those log entries may be valid.
Here's what I have for my ACL:
ipv6 access-list IPV6_EXTERNAL_ACL
permit icmp any any nd-na
permit icmp any any nd-ns
permit icmp any any echo-reply
permit icmp any any hop-limit
permit icmp any any time-exceeded
permit tcp any host 2001:470:xxxx::2 eq 51720
permit udp any host 2001:470:xxxx::2 eq 51720
deny ipv6 any any log
!
Should there be a line to add or remove then? FYI, I mostly see these logs being generated when bittorrent traffic is running.
LoboTiger
Everything you deny is being logged as per your deny statement. The BT traffic is probably causing lots of echo requests because some BT clients, namely uTorrent, have an option to turn on Teredo and lots of people switch it on.
If you want to get rid of the log entries, you can allow echo requests. But this will also allow your IPv6 hosts to be pinged of course. Alternatively, if you want to get rid of the log entries while still disallowing ping, you can put a separate deny entry in there before the last deny to specifically deny echo request, and not put the log option in. Then pings will be silently dropped.