Policy based route based on destination TCP/port

[Dieselboy]

Sri Lanka are not in their office today so I set up a quick test for an internet access change I've been thinking of.

Their site has a 2900 ISR as their router/firewall. I have a layer 7 inspection engine (transparent inline proxy) at the main site only. I'm aware that torrents and other things are sometimes done. So the goal is to implement more security while keeping the same or near-same user experience. Ideally there would be no complaints for normal traffic.

At the moment, the remote site can access internet locally (default route pointing to ISP). There's a branch office VPN between our offices, across the internet using VTI tunnel interfaces. The remote site has one 10MB connection.

To summarise:

Site 1 (main site)
50MB internet
ASA with Sourcefire running VTI tunnels for VPN
internal ISR router also running a VTI tunnel for testing

Site 2 (remote in SL)
10MB internet
single 2900 router where the VTI tunnels are sourced and terminated from

The two tests I done were:
1. configure a policy route-map to look at ANY traffic with a destination port of 80, and set next hop of the far end tunnel

2. add static routes to the ISP so that the VPN tunnel remains up over the internet. Then remove the default route and add a default route with the next hop being the far end of the tunnel

Test 1 was a fail, I think my ACL matching the source as the local site, with a destination of any network but eq 80 must have been incorrect.

Test 2 was a success! I done a internet speed test and got 39.96Mb out of their 10M internet connection due to the wan accelerators but latency to the test site was 150ms due to the lengthy trip. I am anticipating HTTPS traffic to be slow because HTTPS will pass through the wan accelerators unoptimised (so HTTP will be optimised but HTTPS traffic will simply be passed through unchanged). Aside from being slow, we also use voip / video over HTTPS as a cloud application so really I want this to go straight to the internet from the local site.

What I am looking for is to find a way of achieving either of the following:

a) Default route to ISP, policy route to redirect web-traffic
Leave the default route pointing to the local ISP AND a policy route that redirects port 80 traffic (this is test 1 that failed)

OR

b) Default route pointing internally across the VPN, policy to send HTTPS traffic only, to the ISP / local internet

Option B is better as it would mean that I can simply select traffic to send out locally. Then later if I do want to inspect HTTPS then I can optimise that too and treat it like HTTP traffic.

The last option is to replace the 2900 router with some kind of layer 7 inspection box, but this has a cost hence why I'm looking to architect something using existing tools. Plus it's fun. 


Q. With regards to a route map to redirect web traffic, has anyone done this before?

[wintermute000]

Use a FVRF design. Place the branch office internet link into a front VRF. Then run the default route for the global routing table via the tunnel straight to your sourcefire, via normal routing.


Or just buy viptela. SD-WAN service chaining FTW (they are the only vendor that can do this kind of thing properly).

[Dieselboy]

Thanks for the reply. What's FVRF? Not heard of that before. I googled and tried to find more but just found some IPSEC configuration so made me more confused

If I am going to do this, then I want / need to split HTTP and HTTPS traffic separately irrespective of the default route (because the default is only going to point in one direction). So I'll need to discover if it's possible to route based on port 80 or port 443 for example.

[Otanx]

FVRF is a front VRF. In short you setup two VRFs one that has the interfaces for the internet connection, and the second has your internal interfaces, and the tunnel interface. What this does is allows the internet facing VRF to have a default pointed to the internet, and the tunnel will use this routing table to send the tunnel packets. Then you have a default in the second VRF that points over the tunnel so all your internal traffic goes over the tunnel. It is a common configuration for DMVPN type setups.  Take a look at the link below for an example.

http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/46252-grewithvrf.html

-Otanx

[icecream-guy]

http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/46252-grewithvrf.html

-Otanx

that makes my head hurt.

[Dieselboy]

Sweet! Thanks for the explanation and the link!

[wintermute000]

Apologies didn't completely grep your requirements - a Front VRF design will let you take your internet traffic and chain it behind your central Sourcefire, but it won't let you treat 80/443 differently.

That's either an unholy, unscalable, stateless, hop-by-hop mess of PBR, or a SD-WAN problem (pssst Viptella is your answer ROFL).

I don't see why you would want that though TBH, just put all your internets through the central device IF that's what you want.
Or bypass the problem and deploy a cloud proxy solution (e.g. Zscaler or Cisco Web Security or whatever its rebranded to, Umbrella maybe). Given its remote, a cloud proxy makes 100% sense.

[Dieselboy]

Yes you're completely right. I'm just seeing what is possible today with existing tech and I don't need this to scale either. It would be a proof of concept for something that would need to scale 

[wintermute000]

The problem would be return traffic though in theory the SRC port should remain 80 or 443. Again, its the state info that PBR is missing.

[Dieselboy]

Return traffic wouldnt be a problem because I'll nat it outbound so the return has only one way back to the site. The source and dest. ports shouldn't change so that shouldnt be a problem.
I heard you on the PBR - I'm happy to run with that as a silo'd setup / proof of concept / quick and dirty.

[wintermute000]

Let me know how it works