Reverse nPath Routing

HOW DOES BIGIP ACT BY DEFAULT?

By default, BIGIP acts like a Firewall vs. a Router in the sense that BIGIP needs to see the full TCP/UDP Connection in order for BIGIP to add the connection into its Connections Table and thus want to pass subsequent parts of the connection onto the next hop. In a simplistic sense if the BIGIP sees the SYN and the Packet matches the given BIGIP config, BIGIP will then add the connection into its Connection Table. If BIGIP receives a Non-SYN Packet and it doesnt match an existing connection in its connection table, then BIGIP will simply drop the Packet destined to it. Contrast this with a Router, where a Router is willing to route a Packet anywhere it needs to go regardless of whether it saw the original SYN or not. WHAT IS REVERSE nPATH ROUTING?

Reverse nPath Routing is a BIGIP feature that gets around this Firewall type behavior by allowing BIGIP to act a bit more like a router and not have a hard requirement to see every single part of the TCP/UDP Connection thus making the Asymmetric Routing that is common place for a Router to be possible for BIGIP. Reverse nPath Routing is not a F5 Marketing Term. F5 has what they call an nPath Topology that is vaguely similar to this topology, but if you essentially flip the nPath Topology then you get the Flow being described here and thus the term Reverse nPath Routing. WHAT DO THE CLIENT FLOWS LOOK LIKE FOR REVERSE nPATH ROUTING?

To make this topology easier to visualize, lets break the Flows into 2 different scenarios. Scenario #1 is how does an MSN Customer make a request to a BIGIP Virtual Server and have it get serviced properly. We will call this the Client Flow.

The actual Client flow here is pretty vanilla with nothing fancy happening. The Client makes a request to the BIGIPs Virtual Address and its not SNAT-ted at all. The Server simply responds back to the BIGIP directly since the BIGIP is its Default Gateway.HOW ARE DIRECT SERVER CONNECTIONS MADE USING REVERSE nPATH ROUTING?

To make this topology easier to visualize, lets break the Flows into 2 different scenarios. Scenario #2 is how does any off Network Client make a request to the Server directly behind BIGIP and have it get serviced properly. We will call this the MGMT Flow, since this usually occurs when an off-network Host needs to make a connection to the Client for direct Server Management type functions such as MOM, AD, backups, etc.

Here is where the magic of nPath comes into play. The Off Network Management Client makes a request for the actual Servers IP this time instead of the Virtual Server on the BIGIP. The Router receives this request and then ARPs for the owner of the Destination IP. The Server then responds to the ARP and thus receives the SYN. The Server then responds to the connection with a SYN-ACK but sends it to the BIGIP instead of the Router since BIGIP is its Default Gateway for all off-network Traffic. Without doing the Reverse nPath Config, BIGIP using a default config would be confused since it acts as a Firewall and it never actually saw the original SYN to the Server from the Router. Given a normal config it would then drop the attempted Server SYN-ACK response since it knows nothing of the original SYN. Using Reverse nPath, BIGIP sees the SYN-ACK, never saw the SYN, and says Fahgetaboutit. BIGIP accepts the Servers SYN-ACK using the 0.0.0.0 Virtual and then checks who the Pool Members are for this Virtual Address. BIGIPs Pool members here are both of the HSRP Addresses of the Router above it and thus BIGIP does not rewrite the packet at all and simply hands the packet to the Router which can then take care of the rest.WHAT ARE THE SECURITY IMPLICATIONS OF THIS?

The key security challenge with using BIGIPs Reverse nPath Feature is that BIGIP does not see the initial SYN in the conversation. As such, key security pieces of BIGIP do not come into play such as SYN Cookies. However if one of the Direct Server IPs was to be DOS-ed (which would then partially spill over into BIGIP), BIGIP would still have some key defenses in place such as the Connection Reaper which would essentially help mitigate the DOS risk by aggressively reaping stale connections if BIGIPs Memory started getting filled up. While the BIGIP would be better protected from the DOS thanks to its Connection Reaping, the Servers being attacked would have nothing to protect them from the DOS Attack (unless there was a Cisco Guard Upstream). However this lack of Server DOS Protection already is true of many currently deployed MSN Properties such as MSN Messenger, Hotmail, etc. that have Front End Servers with no protective proxy (Load Balancer, Firewall, etc.) between them and the client so this is no more or less of a security risk that we already have in many places. As far as the security risk of BIGIP acting as more of a router than a Firewall and passing Traffic up to the router above it, this is of course what all of our Routers already do today so this is no more or less secure than if BIGIP was just a Router. Overall the key loss in BIGIP security is that we lose the extra protection of SYN Cookies for any attacks to the Direct Server IP. For any attacks on the BIGIP Virtual itself, we would still have SYN Cookie protection.HOW DO I CONFIGURE THE REVERSE nPATH CONFIG?

There are three key parts to special sauce that makes the Reverse nPath config work, configuring the Virtual, the Pool, and the Profile.FASTL4 SUMMARYCreate the default GNS FastL4 Profile

Accept all of the defaults except for:

Profile Setting Enable Loose Connection

Profile Setting Enable loose Close

Idle Timeout Set to 60 Seconds

FASTL4 Settings Deployment Syntax

b profile fastL4 fastl4_reversenpath_default_gns_pr { idle timeout 60 loose initiation enable loose close enable }Create the property specific FastL4 Profile inheriting from the GNS default profile

b profile fastL4 fastl4_reversenpath_msgr_pr { defaults from fastl4_reversenpath_default_gns_pr }POOL SUMMARYCreate a Pool using Round Robin Load Balancing

For the Pool Members use the HSRP Uplink IPs for the BIGIPs and then for the port use 0Pool Settings Deployment Syntax:b pool reversenpath_msgr_0_pl { lb method round robin member 207.46.104.1:0 207.46.104.2:0 }

VIRTUAL SUMMARYCreate a Network Virtual Address of 0.0.0.0:0 with a mask of 0.0.0.0 to pick up any requests sent to the BIGIP with any DestinationAssociate the VIP with the custom FastL4 Profile you created from above

Virtual Settings Disable Address Translation

Virtual Settings Disable Port Translation

Virtual Settings Protocols All Protocols

Virtual Settings Deployment Syntax

b virtual reversenpath_msgr_0_pl { destination any:any pool reversenpath_msgr_0_pl vlan v300 enable profile fastL4_reversenpath_msgr_pr }WHAT DOES AN ACTUAL REVERSE nPATH BIGIP CONFIG LOOK LIKE?BIGIP VIRTUAL SERVER

[root@CRAZYEYES01:Active] config # b virtual nPath list

virtual nPath {

destination any:any

profile npath

pool Router

}BIGIP VIRTUAL ADDRESS[root@CRAZYEYES01:Active] config # b virtual address 0.0.0.0 list

virtual address 0.0.0.0 {

arp disable

}

[root@CRAZYEYES01:Active] config #

BIGIP PROFILE[root@CRAZYEYES01:Active] config # b profile fastL4 list

profile fastL4 npath {

defaults from fastL4

loose initiation enable

loose close enable

}

profile fastL4 fastL4 {

reset on timeout disable reassemble fragments disable

idle timeout 300

mss override 0

pva acceleration full

}

BIGIP POOL[root@CRAZYEYES01:Active] config # b pool Router list

pool Router {

member 15.0.0.1:any

}_1175957405.vsd

TUK-F64F-1A

SINGLE NIC TOPOLOGY Reverse nPATH

BIGIPDG: ROUTER

_1175985409.vsd

TUK-F64F-1A

SINGLE NIC TOPOLOGY Reverse nPATH

BIGIPDG: ROUTER