A GRE (Genereic Routing Encapsulation) is a tunneling protocol that allows data to be encapsulated and sent over a simulated point-to-point link. The beauty of it is that it will encapsulate many different types of traffic and De-encapsulate it on the other. This basically means any traffic sent to the tunnel interface will be stuffed it in a envelope and sent to the remote gateway, removed from the envelope, and forwarded normally. The network which the traffic is being routed across only sees GRE and not the individual IP header. A GRE tunnel can be used with or without IPSEC for encryption. This blog entry creates a tunnel WITHOUT IPSEC.
This is not only a one of the only ways to get Routing updates/traffic such as OSPF across a IPSEC VPN, but also is a wonderful troubleshooting option.I have seen this be a great troubleshooting tool when an MPLS might be blocking traffic.
Recently I have utilized a GRE tunnel to tunnel all multicast traffic across a MPLS network that does not support multicast. By tunneling all the Mulicast data, the MPLS only saw GRE packets and the multicast streams worked great.
In this post I will demonstrate how to create a GRE tunnel between two Fortigate firewalls. Traffic will then be encapsulated from the source and de-encapsulated and forwarded normally on the remote end point. Most of the GRE configuration within the Fortigate is CLI only and not something that can be configured in the GUI.
Steps needed
The process is relatively straight forward and simple. First we need to create our GRE tunnel. The two sites we will be creating the tunnel on are Site-A, and Site-B.
Here is an overview of the network
CLI commandsconfig system gre-tunnel
edit “GRE-to-SITEB”
set interface “WAN1”
set remote-gw 2.2.2.1 — Remote firewall WAN IP
set local-gw 1.1.1.1 — Local FW WAN1 IP
next
end
config system interface
edit “GRE-to-SiteB”
set vdom “root”
set ip 192.168.254.1 255.255.255.255 — Local Tunnel IP
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.2 — Remote Tunnel Endpoint IP
set snmp-index 65
set interface “WAN1”
next
end
Now we can create the static route pointing my remote traffic (10.2.2.0/24) through the GRE-to-SiteB GRE tunnel.
Next we need to create the Firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface or whichever interface your traffic originates on.
GRE Tunnel creation
config system gre-tunnel
edit “GRE-to-SITEA”
set interface “wan1”
set remote-gw 2.2.2.1
set local-gw 1.1.1.1
next
end
config system interface
edit “GRE-to-SITEA”
set vdom “root”
set ip 192.168.254.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.1
set snmp-index 8
set interface “wan1”
next
end
Now we can create the static route pointing my remote traffic (10.1.1.0/24) through the GRE-to-SiteA GRE tunnel.
Next we need to create the Firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface or whichever interface your traffic originates on.
That should be it.
Now lets see if we can ping across our tunnel. As shown below pings work great! Pinging both the tunnel interface and across the tunnel are great ways to check if this tunnel is actually working. Odds are if you have enabled ping on the tunnel interface, and cannot ping it from the other side then the tunnel is not working. Also, check the Firewall policy count to make sure it is increasing with traffic – if so everything is working .
Thanks!
Sometimes it is necessary to change IP address used to talk with the internet that the internal client is using. For instance it is always important to make sure your SMTP server is using the same outbound IP used for inbound traffic. I have seen this cause a good many mail servers to be blacklisted by ISPs. In the following entry we will change the IP the client is using for outbound nat.
This technique has many awesome benefits, you can nat into this IP (IP pool) only when going to a certain destination.. etc. For example, if you had to change your source IP when accessing a destination across a VPN tunnel. That example might be very important in a medical field where I have found you almost always have to nat your private traffic to a public address when accessing the VPN hosts.
The internal client address is 10.64.16.10, external IP is 1.1.1.1. In this example I only want this one internal client to be natted out of 1.1.1.1
So we have to create a Virtual IP pool . We create the Virtual IP pool by going to Policy and objects – objects – IP Pools
We then can setup the pool. Notice the options
– Overload allows PAT, so many ip addresses, to one public.
– One-to-One allows one IP to that public IP
– We also have the option to nat into a Public Range of addresses
We also want this device to answer VIA Arp for 1.1.1.1
Now lets create our IPv4 Policy to allow our private IP address to be allowed to the internet (WAN1) and to be natted VIA this IP pool. I created the address object for my private host already.
So after creating our IPV4 policy, we have one thing left to do – make sure this is one of our first policies hit when 10.16.64.10 tries to access the internet. So lets make sure its at the top of our list, or at least above our default nat rule.
That’s it! if you now go to a site such as ipchicken.com or whatismyip.com you will see 1.1.1.1 if you are coming from 10.16.64.10.
The other day I had the need to plug a Ruckus Access point directly into the Fortigate firewall. The client only needed 1 AP, and connecting directly into one of the ports on the Fortigate was the best way – PoE was provided by an injector.
The question came up of how to create the Vlan interface when directly connecting the device to Fortigate.
In this example I will create the vlan on the Internal switch “lan”, and control the vlan from the Ruckus Zonedirector. This will create two separate logical interfaces. Internal, and Staff-Wireless, my newly created vlan. These two interfaces will require IPV4 policies to allow communication. If you have a lot of VLANs it might be a great idea to utilize Zones in the FW to reduce the number of firewall policies needed.
Lets get started
Vlan creation of Fortigate
So, lets create the vlan for “Staff-Wifi” Vlan 200. You can just create
Now lets put in the needed info.
The below shows the status of the interface:
Notice the VLAN ID – this is seen by right clicking the column settings and enabling that.
Thats it! The Ruckus AP will tag “Staff-Wireless” traffic as vlan 200. So, when the FGT sees the vlan tag of 200 on any ports in the lan switch, it will be treated as Staff-Wifi, thus getting all of its network and policies.
To make the AP work correctly, it needs to be plugged directly into the FGT or a switch behind the FGT that has the vlan created and that vlan would need to be tagged on both the AP and uplink to Fortigate.
Below shows the advanced options of my Ruckus ZD. I am tagging the Staff-Wifi SSID as vlan 200.
Remember on the Ruckus side only vlan 200 is being tagged for Staff-wifi AP management traffic is untagged – so it would be on my “LAN” switch network.
Recent Comments