GRE tunnel in FTD

In this article, I want to demonstrate how prefilter policy in FTD will work and how it will deal with tunnel traffic. Traffic like GRE, IP-in-IP

Also, we will talk about how rezone is working in prefilter policy.

You can see the topology in above picture and video of this article here:

In this topology as you can see, we have one FTD in middle and we have to zones:

• INSIDE
• DMZ

We have also two servers and two clients, one pair (client1 - server1) are behind the GRE tunnel and one pair (client2 - server2) is connected through FTD without passing any GRE tunnel. The GRE tunnel is between our two CSR routers.

Let us do some verification, Configuration on CSR tunnel

As you can see in this picture we can see on CSR-client tunnel

And here is the setting for tunnel interface on CSR-DMZ side

Now, we verify the IP address of client1

We make a trace from client1 to server1 (going through the GRE tunnel)

The traffic is going through 50.50.50.2, which in the tunnel interface of CSR in the DMZ!

In this step we verify the IP address of client2

Trace from client2 to server2

As you can see, it won't use the GRE tunnel.

We are going to FMC to start configuration for GRE traffic. First, we should notice that the system has a default prefilter policy, you cannot add rules here. But you can change default action. Default is "ANALYZE all tunnel traffic." You can modify it to “Block all tunnel traffic.” So, it means that the system, by default, will Analyze all tunnel traffic.

Now here is the question. What does "ANALYZE" do??

"Analyze means that I will pass the tunnel traffic into snort instance so you can filter it in ACP!”

Our first step is creating a rule for tunnel traffic on prefilter policy.

To achieve this, go to Policies > prefilter >new policy

The next step is creating a tunnel rule

Please pay attention that this tunnel rule only applied to non-encrypted tunnel. Check the encapsulation & ports tab.

We have three options in our action menu.

• Fastpath
• Block
• Analyze

We will explain every single option with example.

Fastpath

Fastpath means the tunnel traffic will bypass the snort instance and in the connection event, we will see the fastpath log. Check this out:

And in FTD packet processing we should see it

Now I will try to generate some traffic (from the client that is behind GRE tunnel), and let's see the event connection:

Important note:

In connection event, we will see the outer IP address of the GRE tunnel, and we won't see the client or server IP address because they are inner IP!

BLOCK

Now we will try to block the GRE tunnel in prefilter policy. Let’s change the rule:

Now we expect that even tunnel interface on our CSR routers stop working! Let's see:

And we will see block action in FMC connection event

If you notice, you will see the only outer IP address of the GRE tunnel!

Analyze

With analyze, we will pass the traffic (like regular traffic) into "snort instance."

***KEY NOTE****

If you choose to analyze the tunnel traffic, the ACP will see inner IP address!

Time to do some lab:

We will create a rule to make our GRE traffic get analyzed (default of prefilter policy is also analyze)

If we choose analyze tunnel traffic, the logging in prefilter is not available.

Now, I want to make some traffic and check it out in the connection event.

Now I am generating some ICMP traffic with ping

In this step start RDP session to server1.

And open a web page using server1’s IP address with port 8080

Check out the connection event to see the logs:

As I mentioned before, in ACP, we will see the inner IP address of the GRE tunnel, so here we can see the actual IP address of the client and server!

Now the cool staff!

I want to filter some traffic inside the GRE tunnel. Let's filter and block RDP, HTTP but let ICMP works.

So, let us start some traffic and check the connection event:

ping is permitted

Now try RDP

RDP protocol is not working because we already blocked it in our ACP rule.

Now try open web page:

As we expected the web page also blocked by rule

I will now go to the event connection page to check and verify the logs.

REZONE

The issue with previous configuration is if we want to block traffic like RDP just for a client behind the GRE tunnel, it's not possible! The problem is we are blocking all RDP traffic even from clients that are not behind GRE!

SOLUTION: The solution is rezoning!

In prefilter policy, we have the rezone option. It acts like a new tag, and ACP can use the label in the rules.

Check the picture:

Now in ACP, I can use this tag and filter traffic for only client behind GRE tunnel:

And the result of ACP rules is like this:

Now we can filter and block only traffic behind our GRE tunnel and other computers working fine (like client2 in our topology)

Here is my client1 again with ICMP permit and RDP block.

But meanwhile, I can do RDP and open a web page on my client2 (which is not behind GRE tunnel)

So, I can browse my server2 webpage without any issue.

And for final verification, I will go to event connection to see the logs.

Thank you very much and waiting for your feedback!