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 SUMMARY
Create 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 SUMMARY
Create 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 0
Pool 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 SUMMARY
Create 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 Destination
Associate 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
}