Tear Down This Wall! (Or at least punch a hole in it)

Back in 1987, President Reagan stood at Brandenburg Gate in Berlin and issued these iconic words: "Mr. Gorbachev, tear down this wall!" Sure, there was a path from east to west during the cold war at Checkpoint Charlie, but the existence of said path and the ability to traverse that path were not one in the same, at least among those valuing their life.  At this point you might be asking what the heck this has to do with BIG-IP? Well, let me tell you! One of the more common misconceptions about BIG-IP concerns routing. A route (n) is (as defined in the Google) "a way or course taken in getting from a starting point to a destination." So far so good. Routes are easy to add and easy to follow. Static routes anyway.

I believe the confusion lies in the fact that the BIG-IP is a default deny box. That means, like Checkpoint Charlie, just because there is a path doesn't mean that traffic is going to be allowed on that path. This is not an "If you build it, they will come" situation, as much as it pains me to break it to Ray Kinsella there to the right. In order for traffic to flow through the BIG-IP, it has to be explicitly allowed and this is done with virtual servers. Virtual servers are the tearing down (or punching holes) of the BIG-IP default deny wall. Whether you need to route all protocols for specific networks, or deliver a variety of applications, you can configure specific or wildcard servers of many different types, meticulous details of which can be found in Solution 14163. For a specific example, consider this question raised in Q&A yesterday. The original poster wanted to be able to route some traffic between vlans with no translation, while allowing translation on other traffic. Again, all this work is done in the forwarding configuration, not the routing configuration.

Assumptions:

• outside vlan: 172.16.100.0/24 (nat outbound traffic to this subnet from inside vlans)
• inside vlans: 192.168.1.0/24, 192.168.2.0/24 (do not nat traffic between these or to the remote servers)
• ipsec link vlan: 192.168.99.0/24
• remote servers: 192.168.100.0/24 (do not nat internal server traffic to remote servers)

The diagram (remote servers on other side of a ipsec tunnel):

Alexander came up with a working configuration after seeding the discussion with some of the above concepts, go check it out!