NAT with GRE tunnel issue
-
Hi all,
I’ve got an interesting yet unusual issue I’m trying to solve for a number of our customers. I work for an IT support which looks after a number of schools. A number of those schools make use of an internet filtering service provided by a specialist company. We’ve used monowall and now PFsense for several years, both very successfully.
The filtering service is generally implemented by replacing the customer’s ADSL router with a Cisco 800 series router configured so as to redirect HTTP/HTTPS traffic to the filtering company’s servers. This is done in an unusual, but effective manner. Specifically, it works as follows.
First, the router is configured to set up a GRE tunnel to the filtering company’s network. The GRE tunnel’s near end has the IP 192.168.242.117/30 and the far end is 192.168.242.118/30 in this example.
Traffic on the LAN destined for the internet on TCP 80 or 443 is NATed (with the WAN’s interfaces IP address), and then routed down the GRE tunnel, rather than heading towards the WAN interface directly. All other traffic is NATed (with the WAN ip address) and routed out the WAN interface, as usual.
I've attached a (nasty) schematic below.
If you do a packet capture, packets appear as follows:
Outer IP Packet – Source: 60.60.60.60, Destination: 80.80.80.80
GRE encapsulating…
Inner IP Packet – Source: 60.60.60.60, Destination: 74.125.237.49
TCP Datagram – Source port: 1234, Destination port: 80
HTTP Request: GET www.google.comThis is slightly unusual as far as GRE packets go; inner packet’s source would generally be the IP of the originating workstation, for example, not the WAN IP address.
The idea is that the filtering appliance will remove the outer IP packet, scan the outgoing HTTP request (it will only see half the HTTP conversation – the outbound requests), then pass on a good request to the destination webserver. That webserver will then respond and send the response directly back to the customer, not via the filtering appliance and not via the GRE tunnel, as the packet the webserver receives contains the customer’s WAN IP address, not the filtering appliance’s. This also means the connection path is asymmetrical.
Given that most web browsing consists of downloading, this means the filtering company’s internet feed doesn’t need to be ridiculously fast.
The down side is that we don’t have control of this gateway device (ie: the Cisco router), which is becoming increasingly important. Double-NAT isn’t an option either as that just complicates firewall and inbound NAT administration. We’d rather use PFsense as the gateway router, as this gives us much more transparency.
I’ve tried duplicating this configuration on PFsense, but without much joy so far. I’ve got the tunnel working, but end up with one of three difference scenarios; none of which quite work.
I’d assumed I’d be able to create a pair of firewall rules (for outgoing HTTP, HTTPS) to route those packets to a gateway (the far end of the tunnel using the far end IP address), and use an advanced outbound NAT rule to translate those packets so they appear to come from the WAN IP address.
Unfortunately when I set up the NAT rule to use the WAN IP’s address, this seems to override the firewall rules, and the packets end up going out the WAN interface instead.
Is it possible to configure PFsense, such that outgoing packets destined for TCP port 80 and 443 are NATed with the WAN interfaces’ IP address, BUT are routed through the tunnel, rather than through the WAN interface?
Thanks for your time!
Cheers
JC
-
Which service are you using to setup the GRE tunnel?