GRE tunnel and ip access-group command

[sarahr202]

Hi everybody

Please consider the following:

R1---gre-tunnel----R2

R1's routing table:

S    12.0.0.0/8 is directly connected, Tunnel0

S    13.0.0.0/8 is directly connected, Tunnel0

The goal is to stop any packet destined at 12.12.12.2 from going through tunnel0 at R1.

int tunnel 0

ip address 10.10.10.1/8

tunnel source 10.10.10.1

tunnel destination 200.200.200.3

access-list 103 deny ip any host 12.12.12.2

access-list 103 permit any any

The question how to use "  ip access-group 103 "  under tunnel 0 ? It should be "in"  or " out"  ?

To put it simply If i Use " ip access-group 103 in under tunnel interface, Does it mean access-list 103 is applied to packets entering the tunnel from R2?  or  does it mean  packets that need to be forwarded out of tunnel 0, are first checked against the access-list 103 before they could be tunneled?

Thanks and have a great day

[cflory · Accepted solution]

You could either apply 'ip access-goup 103' "in" on the Tunnel0 interface of R1, or "out" on an Ethernet interface of R1.

Here's some info that might help make sense for you:

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml

Define In, Out, Inbound, Outbound, Source, and Destination

The router uses the terms in, out, source, and destination as       references. Traffic on the router can be compared to traffic on the highway. If       you were a law enforcement officer in Pennsylvania and wanted to stop a truck       going from Maryland to New York, the source of the truck is Maryland and the       destination of the truck is New York. The roadblock could be applied at the       Pennsylvania–New York border (out) or the Maryland–Pennsylvania border (in).

When you refer to a router, these terms have these meanings.

• Out—Traffic that has already been through the router           and leaves the interface. The source is where it has been, on the other side of           the router, and the destination is where it goes.

• In—Traffic that arrives on the interface and then           goes through the router. The source is where it has been and the destination is           where it goes, on the other side of the router.

• Inbound —If the access list is inbound, when the           router receives a packet, the Cisco IOS software checks the criteria statements           of the access list for a match. If the packet is permitted, the software           continues to process the packet. If the packet is denied, the software discards           the packet.

• Outbound—If the access list is outbound, after the           software receives and routes a packet to the outbound interface, the software           checks the criteria statements of the access list for a match. If the packet is           permitted, the software transmits the packet. If the packet is denied, the           software discards the packet.

The in ACL has a source on a segment of the interface to which it is       applied and a destination off of any other interface. The out ACL has a source       on a segment of any interface other than the interface to which it is applied       and a destination off of the interface to which it is applied.

[sarahr202]

Hi cflory

I configured the access-list to deny any ip packet from 199.199.199.1 destined at 4.4.4.4 from being tunneled.

Below is the set up.

R1s0/0----199.199.199.0--- s0/0R2 s0/1---------s0/0-R3 s0/1---------------s0/0R4 loopback 4.4.4.4

A GRE tunnel is configured between R2 and R4

Thus the above set up can be simplified as:

R1 s0/0-----199.199.199.0----R2---GRE tunnel----R4

The goal is stop any ip packet with src 199.199.199.1 dst 4.4.4.4 from going through the tunnel at R2.

R2 config:

interface Tunnel0

ip address 10.10.10.2 255.0.0.0

ip access-group 103 in

tunnel source 2.2.2.2

tunnel destination 201.201.201.4

access-list 103 deny   ip host 199.199.199.1 host 4.4.4.4

access-list 103 permit ip any any

R2 routing table:

R2#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    200.200.200.0/24 is directly connected, Serial0/1

R    201.201.201.0/24 [120/1] via 200.200.200.3, 00:00:10, Serial0/1

C    199.199.199.0/24 is directly connected, Serial0/0

C    2.0.0.0/8 is directly connected, Loopback2

S    4.0.0.0/8 is directly connected, Tunnel0

C    10.0.0.0/8 is directly connected, Tunnel0

R1 routing table:

Gateway of last resort is not set

R    200.200.200.0/24 [120/1] via 199.199.199.2, 00:00:22, Serial0/0

R    201.201.201.0/24 [120/1] via 199.199.199.2, 00:00:22, Serial0/0

C    199.199.199.0/24 is directly connected, Serial0/0

R    2.0.0.0/8 [120/1] via 199.199.199.2, 00:00:22, Serial0/0

S    4.0.0.0/8 is directly connected, Serial0/0

R1 s0/0 ip address 199.199.199.1/24

R1# ping 4.4.4.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 300/320/328 ms

===========================================================

My question is  ping should not have been successful because:

When R2 receives the ping packet with src ip 199.199.199.199.1 dst on 4.4.4.4, R2 checks the routing table and finds it has to use tunnel0 to forward it.

Next R2 finds the " ip access-group 103 in " under tunnel 0 which causes the R2 to check the packet against the access-list 103.

As per access-list 103, R2 should have dropped the packet but it did not.

The question is why?

Any insight will be greatly appreciated.

Thanks

[Edison Ortiz]

If you want to block the ping, the access-group should be configured in the 'out' direction... From R2 to R4.

Regards,

Edison

[sarahr202]

Hi Edison

If we configure ip access-group 103 out  under tunnel 0 at R2,  how are the packets  examined against the access-list?

For example

When R2 receives a ping packet  will it encapsulate the  original ping packet  with tunnel source ip 2.2.2.2  tunnel dest ip 201.201.201.4 and  then check the packet against the access-list?  Or it will first check the original ping packet against the access-list 103 ?

access-list 103 deny   ip host 199.199.199.1 host 4.4.4.4

access-list 103 permit ip any any

=================================

If I use " ip access-group  103 in " under tunnel interface  what does it mean ?

For example  when above command is configured under a regular interface, it simply means  incoming packets are checked against the access-list.

Is it same with tunnel interface as well?

I have this confusion that If I configure " ip access-group 103 in"  under tunnel 0, at R2,  I am instructing R2 to check all the packets that need to be tunneled out against the access-list 103, If they are permitted,adds GRE header with appropriate tunnel source ip and destination ip and sends them out of tunnel; if they are not permitted, simply drop them

Is this correct?

Sorry for the long -winded reply.

Thanks and happy holidays

[cflory · Accepted solution]

Encapsulation happens after the access-list check.  So, as Edison eluded to, apply your ACL as an out function on your R2 Tunnel 0 interface "ip access-group 103 out".  The packets will be checked by the ACL first, and if your ping matches the deny rule in your ACL, the packet will be dropped before encapsulation.  If the ping does not match the deny statement in your ACL, it will be encapsulated and sent on.

As you can see from this table that is more geared for NAT clarification, but nonetheless, you can see the order of operations.  GRE encapsulation occurs down before encryption:

Inside-to-Outside

Outside-to-Inside

If IPSec then check input access list decryption - for CET (Cisco Encryption Technology) or IPSec check input access list check input rate limits input accounting redirect to web cache policy routing routing NAT inside to outside (local to global                       translation) crypto (check map and mark for encryption) check output access list inspect (Context-based Access Control                       (CBAC)) TCP intercept GRE encapsulation encryption Queueing

If IPSec then check input access list decryption - for CET or IPSec check input access list check input rate limits input accounting redirect to web cache NAT outside to inside (global to local                       translation) policy routing routing crypto (check map and mark for encryption) check output access list inspect CBAC TCP intercept encryption Queueing