Installation guide

Deployment Flexibility
Sentriant AG Software Installation Guide, Version 5.2
15
● Router IP—10.1.90.254, on a /24
● Sentriant AG IP—10.1.90.130, on a /24
● VPN concentrator IP—10.1.90.131, on a /24
● VPN client IP range—10.1.105.0/24
The VPN concentrator is configured to hand out IP addresses on the 10.1.105.0/24 subnet, while
Sentriant AG and the VPN concentrator itself are on the 10.1.90.0/24 subnet. Both Sentriant AG and the
VPN concentrator have a default route set through 10.1.90.254 which is a router or Layer 3 switch on
the LAN (eth0) side of Sentriant AG.
Because a connecting VPN endpoint is not on the same subnet as Sentriant AG, all of the packets that
Sentriant AG sends (in response to HTTP requests from the endpoint) go to the router at 10.1.90.254,
which knows to send them (back through the Sentriant AG bridge) to the VPN concentrator for a next
hop. For normal communication (such as testing traffic) between Sentriant AG and an endpoint, this
works fine, even if it seems a bit inefficient.
However, when Sentriant AG redirects an HTTP connection, it first constructs an HTTP redirect with a
source IP address corresponding to the original destination of the connection.
For example:
1 The endpoint connects to the VPN, and the browser requests www.google.com.
2 Sentriant AG intercepts the packets addressed to google.com.
3 Sentriant AG constructs an HTTP redirection to the Sentriant AG IP, using packets which have a
source IP address of www.google.com.
4 Sentriant AG sends the constructed redirect to the VPN endpoint using the Sentriant AG default
route.
Those packets go to the LAN side router, which in our scenario is configured with best-practices egress
filtering. The router treats those packets as errors (because they are marked with a source IP address
that should not emanate from that network segment) and drops them. This is why testing works when
the endpoint connects directly to emanate—the response packets still go to the LAN-side router, but it
routes them appropriately because they have a valid source address.
The solution is to add a static route to Sentriant AG so that it knows to send packets addressed to
10.1.105 via the VPN concentrator instead of the LAN-side router, and it will redirect correctly.
You also want to make the static route addition permanent across reboots.
To add a permanent static route to the Sentriant AG server:
1 Log in as root to the Sentriant AG server using SSH or directly with a keyboard.
2 Open the following file with a text editor, such as vi.
/etc/rc.local
3 Add something like the following:
#