How to route packets back to incoming interface?

Hi folks,

I have a debian server running an Apache daemon on the eth0 interface. Now from time to time the server has to open an openvpn connection (tun0) to other networks to get some data from there. During this period the Apache is no longer reachable under it's IP address on eth0 because all outgoing traffic is routed over tun0.

I'm not that firm in routing, so what can I do, so all incoming packets are answered over the interface they came in and all outgoing traffic what is initiated by the server itself runs over tun0?

Routing table w/o openvpn connection:

    root@j305934:/# route
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    default         sw-gate05.jiffy 0.0.0.0         UG    0      0        0 eth0
    134.119.3.0     *               255.255.255.0   U     0      0        0 eth0
    
    root@j305934:/# ip route
    default via 134.119.3.254 dev eth0
    134.119.3.0/24 dev eth0  proto kernel  scope link  src 134.119.3.16

Routing table with active openvpn connection:

 
    root@j305934:/# route
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    default         10.200.195.1    128.0.0.0       UG    0      0        0 tun0
    default         134.119.3.254   0.0.0.0         UG    0      0        0 eth0
    10.200.195.0    *               255.255.255.0   U     0      0        0 tun0
    62.113.251.130  134.119.3.254   255.255.255.255 UGH   0      0        0 eth0
    128.0.0.0       10.200.195.1    128.0.0.0       UG    0      0        0 tun0
    134.119.3.0     *               255.255.255.0   U     0      0        0 eth0

    root@j305934:/# ip route
    0.0.0.0/1 via 10.200.193.1 dev tun0
    default via 134.119.3.254 dev eth0
    10.200.193.0/24 dev tun0  proto kernel  scope link  src 10.200.193.43
    62.113.251.130 via 134.119.3.254 dev eth0
    128.0.0.0/1 via 10.200.193.1 dev tun0
    134.119.3.0/24 dev eth0  proto kernel  scope link  src 134.119.3.16

I don't quite get what you are trying to do. Maybe you want TAP - bridge from eth1: to eth0: Which you not have now. In other words segregate and bridge on this server. Is this box in the DMZ?

Mmmh. Ok let me try to eplain it...

The server hast 1 NIC (eth0) and is connected to the internet. There are several daemons running on it (Apache, FTP, ...). Now from time to time a script running on the machine has to connect by openvpn to some other servers of which I know only the domain name not the ip addresses because they change they rotate ips due load balancing and also have alot of IP ranges.

Now when script opens up a openvpn link (tun0) to connect to a openvpn host, all traffic of my server is then routed over the tun0 gateway. Therefor if some client tries to reach the Apache daemon under it's common address, he get's no reponse, because the reponse packet are not sent back on the eth0 interface but the tun0 route. So no more connection to the daemons are possible anymore until the openvpn connection is closed.

What I want now, is that the server responds to any ip packet it gets, on the same interface it was received. When the vpn link is up, all outgoing packets of tcp/udp traffic which were initiated by the server itself have to be routed to tun0, all answers on incoming packets on eth0 have to be answered to eth0.

Does this make any sense to you? :wink:

Yes. You have to bridge somehow - that is what TAP does.
Does this link look familiar?

BridgingAndRouting � OpenVPN Community

Mmmh not to familiar with it - even after reading :frowning:

Another approach would be if it's possible to route only the traffic on 1 application (or user) over the vpn tunnel by removing the default gateway to it and let all remaining traffic on eth0.

I think there was some way with iptables to mark packages of a user and apply some postrouting rules to change the ip and route them over a different interface, but I really can't remember how anymore :wink:

Is the VPN something you control? You're using it in bridging mode, which takes over your connection, but if you use routing mode, it doesn't... Routing mode just allows you to connect to a new subnet of IP's.

I would not add a default route for the tun0.
Once it is present, I would try to delete it, with

route delete default 10.200.195.1

or similar.
AFAIK in a standard IP stack there is no way to return packets to the incoming interface - it always follows the routing table.

1 Like