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.

FTD

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

FTD

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

FTD

Now, we verify the IP address of client1

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

FTD

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

FTD

Trace from client2 to server2

FTD

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!”

FTD

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

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

FTD

 

The next step is creating a tunnel rule

FTD

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

FTD

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:

FTD

And in FTD packet processing we should see it

FTD

 

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

FTD

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:

FTD

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

FTD

And we will see block action in FMC connection event

FTD

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."

FTD

***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)

FTD

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

FTD

In this step start RDP session to server1.

FTD

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

FTD

Check out the connection event to see the logs:

FTD

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.

FTD

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

ping is permitted

FTD

Now try RDP

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

FTD

Now try open web page:

As we expected the web page also blocked by rule

FTD

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

FTD

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:

FTD

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

FTD

And the result of ACP rules is like this:

FTD

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.

FTD

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

FTD

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

FTD

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

FTD

Thank you very much and waiting for your feedback!

 

2118
0
1
Leave your comment