I have an Internet facing server running pptpd. Users who connect via pptp need to be able to route through the server to the rest of the Internet.
As well as configuring net.ipv4.ip_forward=1 I also have iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
.. and it all works.
However, is the above iptables command too broad for an internet server? Doesn't it effectively mean that anyone can send traffic through it?
Assuming the pptp interface is ppp0 I would have expected (having very little iptables knowledge) that: iptables -t nat -A POSTROUTING -o eth0 -i ppp0 -j MASQUERADE .. would be better but I'm just guessing and I don't want to kill access to the remote server by playing!
Given that every howto I find says to use just "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE" I assume that's actually right, so I think I'm just asking for help understanding why.
Mark
On 2013-04-12 15:02, Mark Rogers wrote:
I have an Internet facing server running pptpd. Users who connect via pptp need to be able to route through the server to the rest of the Internet.
As well as configuring net.ipv4.ip_forward=1 I also have iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
.. and it all works.
However, is the above iptables command too broad for an internet server? Doesn't it effectively mean that anyone can send traffic through it?
Assuming the pptp interface is ppp0 I would have expected (having very little iptables knowledge) that: iptables -t nat -A POSTROUTING -o eth0 -i ppp0 -j MASQUERADE .. would be better but I'm just guessing and I don't want to kill access to the remote server by playing!
Given that every howto I find says to use just "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE" I assume that's actually right, so I think I'm just asking for help understanding why.
Mark
Mark,
The NAT rule is correct, I wouldn't alter that.
What I would do, is add a rule to the FORWARD chain in the filter table to allow this traffic, but drop anything else:
iptables -I FORWARD -i ppp0 -j ACCEPT iptables -P FORWARD DROP
Hope this helps,
Jim
On 12 April 2013 15:51, Jim Rippon jim@rippon.me.uk wrote:
The NAT rule is correct, I wouldn't alter that.
What I would do, is add a rule to the FORWARD chain in the filter table to allow this traffic, but drop anything else:
iptables -I FORWARD -i ppp0 -j ACCEPT iptables -P FORWARD DROP
Thanks, I'll pass that on to the guy configuring the VPN.
iptables is a giant hole in my Linux skills that I really must close!
Mark
On 15/04/2013 08:49, Mark Rogers wrote:
[SNIP]
iptables is a giant hole in my Linux skills that I really must close!
There was a time I did hand-rolled iptables scripts, and very good they were too, even if I say so myself.
However, I had one to do for a client that involved a lot of very complicated stuff, including VPNs between a central office and 3 outlying offices. I took a long hard look at Shorewall, and started using that and OpenVPN.
It takes a little time to get ones head around it, but it's worth it. The documentation is just excellent.
Cheers, Laurie.
On 15 April 2013 09:06, Laurie Brown laurie@brownowl.com wrote:
However, I had one to do for a client that involved a lot of very complicated stuff, including VPNs between a central office and 3 outlying offices. I took a long hard look at Shorewall, and started using that and OpenVPN.
I just had a quick look through the Shorewall introduction, and I think that it's probably a great direction to head in but I'd be much happier having a basic understanding of iptables (and other tools) before I go there.
Still, it's one more thing to add to the list of things to learn!
Thanks.
On 12 April 2013 15:51, Jim Rippon jim@rippon.me.uk wrote:
The NAT rule is correct, I wouldn't alter that.
What I would do, is add a rule to the FORWARD chain in the filter table to allow this traffic, but drop anything else:
iptables -I FORWARD -i ppp0 -j ACCEPT iptables -P FORWARD DROP
Just to let you know: Adding these lines broke forwarding. Specifically the second line (which makes sense).
I have checked and the VPN interface is ppp0. We're running without those two lines quite happily.
Any suggestion what went wrong?
On Fri, Apr 19, 2013 at 04:30:44PM +0100, Mark Rogers wrote:
On 12 April 2013 15:51, Jim Rippon jim@rippon.me.uk wrote:
The NAT rule is correct, I wouldn't alter that.
What I would do, is add a rule to the FORWARD chain in the filter table to allow this traffic, but drop anything else:
iptables -I FORWARD -i ppp0 -j ACCEPT iptables -P FORWARD DROP
Just to let you know: Adding these lines broke forwarding. Specifically the second line (which makes sense).
I have checked and the VPN interface is ppp0. We're running without those two lines quite happily.
Any suggestion what went wrong?
You only allowed forwarding stuff coming into ppp0, not out of it. You probably want:
# Allow anything new out of ppp0 iptables -I FORWARD -o ppp0 -j ACCEPT # Let anything into ppp0 that's already established iptables -I FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED \ -j ACCEPT # Drop anything else iptables -P FORWARD DROP
J.
On Fri, Apr 19, 2013 at 09:22:48AM -0700, Jonathan McDowell wrote:
On Fri, Apr 19, 2013 at 04:30:44PM +0100, Mark Rogers wrote:
On 12 April 2013 15:51, Jim Rippon jim@rippon.me.uk wrote:
The NAT rule is correct, I wouldn't alter that.
What I would do, is add a rule to the FORWARD chain in the filter table to allow this traffic, but drop anything else:
iptables -I FORWARD -i ppp0 -j ACCEPT iptables -P FORWARD DROP
Just to let you know: Adding these lines broke forwarding. Specifically the second line (which makes sense).
I have checked and the VPN interface is ppp0. We're running without those two lines quite happily.
Any suggestion what went wrong?
You only allowed forwarding stuff coming into ppp0, not out of it. You probably want:
# Allow anything new out of ppp0 iptables -I FORWARD -o ppp0 -j ACCEPT # Let anything into ppp0 that's already established iptables -I FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED \ -j ACCEPT # Drop anything else iptables -P FORWARD DROP
Sorry, the context from the initial mail wasn't there so this probably isn't want you want - I think you want the clients coming in over pptp to be able to talk to the network, rather than the network initiating out to the clients. So change the -i to -o in the second command to allow anything established out to the client, and either the -o to a -i in the first command to allow /anything/ in or be more selective in protocols.
J.
On 19 April 2013 17:27, Jonathan McDowell noodles@earth.li wrote:
Sorry, the context from the initial mail wasn't there so this probably isn't want you want - I think you want the clients coming in over pptp to be able to talk to the network, rather than the network initiating out to the clients.
That's correct (I think!).
Users connecting to the VPN should be able to route to anywhere from that VPN connection. The server itself should be able to reach anywhere. But nobody else should be able to route to somewhere else via the server. Does that make sense? (Terminology probably isn't right here, sorry!)
To give an example, if 1.2.3.4 is my server, I need to be able to connect (PPTP) to the server then use 1.2.3.4 as a gateway to reach another server 6.7.8.9 (not on the same network). 6.7.8.9 is configured to only allow access from 1.2.3.4 which is the reason for the VPN in the first place. I don't want to limit PPTP users to accessing 6.7.8.9 at this stage, however I don't want anyone on the wider internet to be able to use 1.2.3.4 as a gateway.
So change the -i to -o in the second command to allow anything established out to the client, and either the -o to a -i in the first command to allow /anything/ in or be more selective in protocols.
So I think this leaves me with: iptables -I FORWARD -i ppp0 -j ACCEPT iptables -I FORWARD -o ppp0 -m state --state RELATED,ESTABLISHED \ -j ACCEPT iptables -P FORWARD DROP
I'll give it a try.
(I worry when playing with iptables via an SSH connection that I might screw something up and block access to myself, so I run the commands directly and confirm they do what I want, and if not I always have the ability to reboot the server remotely to remove the iptables rules if needed. If they do what I want they go into /etc/rc.local. Is that all sensible?)
-- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG
On Sun, 21 Apr 2013 10:10:30 +0100 Mark Rogers mark@quarella.co.uk allegedly wrote:
(I worry when playing with iptables via an SSH connection that I might screw something up and block access to myself, so I run the commands directly and confirm they do what I want, and if not I always have the ability to reboot the server remotely to remove the iptables rules if needed. If they do what I want they go into /etc/rc.local. Is that all sensible?)
One way to avoid locking yourself out when playing with iptables on a remote machine would be to add an entry to root's cron to flush the tables every N minutes or at time X (choose N or X to suit your circumstances). This will ensure that if the worst happens, then the tables will be deleted and you can get back in. But of course that will leave the box exposed for the period in which the tables are empty. Caveat emptor.
Of course, you may wish to save the current tables to a file before flushing so that you know where you were in your experiments.
Mick
(Oh, and of course don't forget to delete the cron entry when you have the rules set up the way you want them........)
---------------------------------------------------------------------
blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
---------------------------------------------------------------------
On 26/04/13 17:34, mick wrote:
One way to avoid locking yourself out when playing with iptables on a remote machine would be to add an entry to root's cron to flush the tables every N minutes or at time X (choose N or X to suit your circumstances). This will ensure that if the worst happens, then the tables will be deleted and you can get back in. But of course that will leave the box exposed for the period in which the tables are empty. Caveat emptor.
Given I do everything in screen now, what I tend to just do is something like
sleep 600;iptables-restore < /etc/iptables.rules (or wherever you saved the previous set of working rules)
In another screen window
On 12/04/13 15:02, Mark Rogers wrote:
I have an Internet facing server running pptpd. Users who connect via pptp need to be able to route through the server to the rest of the Internet.
Do you intentionally want your pptp users to route their internet traffic through the VPN ?
A more normal configuration would be to only route the subnet the VPN endpoint connects them to and leave them routing internet traffic through their default gateway.
Unless of course you want to force them through some proxy/content filtering etc or you want to tunnel their internet access for privacy/security reasons because their connection to the net is less trusted than the endpoint's
On 13 April 2013 19:22, Wayne Stallwood ALUGlist@digimatic.co.uk wrote:
Unless of course you want to force them through some proxy/content filtering etc or you want to tunnel their internet access for privacy/security reasons because their connection to the net is less trusted than the endpoint's
It's the latter.
There's a Windows server with remote desktop enabled but firewalled to prevent access except from a handful of static IPs, which is fine except anyone who needs access from a dynamic IP has a problem. They lived with it until one of the engineers upgraded to BT Infinity not realising that you can't get a static IP on a domestic package (I think it was an extra £25/mo to upgrade to business account with static IP), at which point using a "spare" server for this VPN was suggested. The users configure their VPN connection not to use the remote gateway then add a static route via the VPN for that one server's IP only.
There's actually nothing of interest on the VPN itself.
For added security I guess it could be configured to only route traffic to that server's IP though?
Mark
-
Jim Rippon -
Jonathan McDowell -
Laurie Brown -
Mark Rogers -
mick -
Wayne Stallwood