0

I have OpenVPN and PPTP installed on a VPS. I'm having a few questions that I can't seem to get a firm answer on.

I want to install OpenVPN on 1.1.1.1 (eth0, public IP address) and PPTP on 1.1.1.2 (eth0:1, public IP address). I was able to achieve this with SNAT. However, from all the tutorials I've been reading it recommends forwarding ppp+ to eth0 and vice versa and the same situation for the tun interface.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i ppp+ -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o ppp+ -j ACCEPT

My setup is CentOS, dedicated server.

For some reason I'm assuming iptables will route all traffic from eth0 to tun0 and stop at that.

My question is,

1) Will these forward rules conflict with each other? 2) Will I need to forward the ppp+ to eth0:1 instead to avoid confliction? Is it even possible? I haven't figured out a way yet. 3) Is iptables smart enough to route traffic that is specific to tun and ppp through these rules?

4

First let's try to clean up the situation a bit as you seem to confuse certain things about how packet filtering and routing work together.

  • iptables (actually, Netfilter — that's the name of the in-kernel stack; iptables is just the name of a user-space binary to operate the Netfilter rule sets) does not route anything; routing is done by the routing stack (controlled using the ip user-space binary), and Netfilter is only able to affect the routing by rules installed in the PREROUTING chain (where DNAT could be done).

  • The chain "FORWARD" (of the "filter" table) is being traversed by all the packets coming through the host, that is, not originated on it (those are going via the "OUTPUT" chain) and not destined to it (those are going through the "INPUT" chain).

    Hence yes, if packet forwarding is enabled on the host (and thus the host works as a router) the policy of the chain "FORWARD" and any rules in it do affect the flow of certain packets, but not the routing decisions.

  • Each of the principal three chains — INPUT, OUTPUT and FORWARD has the so-called "default policy", which might be either ALLOW (the default) or DROP. The latter just discards any packet entering the chain. The default policy applies to a packet if the packet wasn't handled by the rules installed in the chain.

  • It's customary for a typical "border gateway" (a host interfacing a LAN to the Internet) to have such a setup so that everything is blocked by default — including forwarding packets via Netfilter, even though it's enabled for the IP stack itself, — and then specific rules inserted to explicitly enable specific kinds of traffic. That is, these tutorials usually advise to set the default policies for INPUT and FORWARD to DROP and then explicitly enable certain kinds of traffic using rules.

  • Which network interface to use for sending packets is decided by the routing stack (Netfilter, again, has no say in this process) based on the routing table(s) and interface metrics, if a specific host/network is reachable via more than one route.

    If you run ip route on your router host, you'll see a set of rules looking like this

    10.8.10.0/24 via 10.8.0.2 dev tun0
    

    where the "via" address designates the next router and "dev" lists the interface to send the packet on to reach that router.

Now let's get back to your situation.

  • You only need to place specific rules in the FORWARD chain if its policy is DROP, otherwise it will "just work".

  • If you DROP packets in your FORWARD chain by default, then you need to explicitly allow passing packets between VPN interfaces and the interface facing Internet, that is, between ppp+ and back and between tun+ and back. If you need the clients of different VPN networks to be able to talk with each other you will also need to enable forwarding of packets between respective interfaces (in both directions).

  • Note that you don't have to refer to interfaces when writing rules for the FORWARD chain (or any other, actually), — you can just use network addresses (for the -s and -d command-line options of iptables).

    Hence, if your VPNs provide two private networks, A and B, you can insert a pair of rules like

    iptables -A FORWARD -s A -d B -j ACCEPT
    iptables -A FORWARD -s B -d A -j ACCEPT
    

    Also, since VPNs usually provide private networks, as do LANs, I tend to just insert something like

    iptables -A FORWARD -s 192.168/24 -d 10/8 -j ACCEPT
    iptables -A FORWARD -s 10/8 -d 192.168/24 -j ACCEPT
    

    to express the idea "everyone is able to talk to everyone else on my private networks" (if you want to also cover the less used 172.16/12 private range, there will be 3x3=9 rules needed, obviously).

Update: note that you do not necessarily have to enable forwarding of packets between VPN interfaces and the interface connected to the Internet: the former are virtual and only carry packets in private networks inside the VPN-provided tunnels; packets that provide these tunnels flow to/from VPN processes running on the host and do not traverse the FORWARD chain. So if you only need your VPN clients to talk with your LAN or between themselves, you only need to enable forwarding of packets between the VPN (and LAN, if present) interfaces.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.