0

Situation: A VPS already serving web pages via nginx. Now I am adding OpenVPN for roaming devices to this VPS.

One installation for the VPN guide suggests adding this MASQUERADE rule -

iptables -A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE

where 10.8.0.0/8 is the VPN virtual address.

Yet browsing around I see many examples of this more general rule -

iptables -A POSTROUTING -o eth0 -j MASQUERADE

with no condition on the source address.

If there are no bad side effects, I would prefer to use the more general rule, then I wouldn't have to worry about it when changing VPN configurations.

I understand the principle of "better safe than sorry", but is there really anything to worry about?

Improve this question
0

2 Answers 2

Reset to default
1

You're invoking the masquerade after you've gone through all of the network stack except the last bit, and this is the last thing you're doing before the packet goes out the door. So this packet has already managed to convince your system it's safe to send outbound. What sources could do that? Either you are letting things forward through your computer you don't want, or you will come up with a very limited set - like maybe localhost and your VPN. If this is the case, your source constraint was already applied earlier and you don't need to duplicate it.

Improve this answer
4
  • Hi - I understand your good point. If there were say a malignant parasitic VPN on the system, wouldn't it already require root access and be able to config the source address before sending? Separately I would like to confirm explicitly was whether there were any possible benign services that send output through eth0 and rely on masquerading not being there?
    – Craig Hicks
    Commented Feb 2, 2019 at 3:51
  • Services on the local system that talk through eth0 already look like they're coming from the local system, so they're not masqueraded, even if their packets pass through that target. I can't tell you what other services exist on your local network. It's conceivable that you have some that require either no masquerading or that the server that is masquerading for them run a masquerade helper module for them.
    – Ed Grimm
    Commented Feb 2, 2019 at 3:57
  • For example, ftp from a system other than your masquerading machine would be one of these. There is, incidentally, a helper module that you could use. Except don't, because FTP should be a relic of the 70s and 80s. Today's Internet is a hostile place that makes some of Bruce Sterling's work look like optimistic sci fi; you should be using encrypted protocols whenever feasible because it's rough out there.
    – Ed Grimm
    Commented Feb 2, 2019 at 3:59
  • That having been said, in many instances when you'd want to have masquerading set up, the systems behind your masquerading server that would require some help to work with it wouldn't work without it, because they'd need to have distinct routing from the internet. Of course, if you have hosts like this and identify them because they stop working, you could easily enough exclude them from your masquerade rule.
    – Ed Grimm
    Commented Feb 2, 2019 at 4:02
0

There may be performance concern for having more general rule. The one which restricts MASQUERADE to only packets with certain source addresses will just do that. The more generic one will apply to ALL packets leaving your system (including locally generated ones) and this may (or may not) increase the load on your VPS.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .