POSTROUTING not accepted by iptables

lpn

Edit2: As the issue is not what I thought it is, I will ask the moderators to close the thread and will post another one if I can't figure out the issue, which could be misconfiguration on the VPN server or client side

Edit: based on rds100's comment (iptables -t nat -L -n), it seems that the rule is there, but I may be missing some modules for this to work or something may be misconfigured either on the VPN server or client side.

Post was:
As the title says, for some reason POSTROUTING is not accepted by iptables. I am trying to set up a VPN, it wasn't working and I tracked it down to this. If I do:
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
and then
iptables -L
there is no mention of the POSTROUTING chain at all.

I know that on some platforms, for this to work something it has to be enabled by the provider on the node (in the kernel?), but this is Xen. Any ideas what may be causing it?

unused

lsmod

what modules are loaded?

Try a: depmod -a

To make sure all modules are picked up- if you are not using a pv-grub or hvm xen instance and your provider is providing the kernel, it could be they didn't include it (or you have to run depmod once to pick it up)

lpn

It appears that none of them are loaded:
lsmod returns just:
Module Size Used by
and depmod -a returns nothing.
Which modules should I ask them to enable?

unused

What kernel are you using ( uname -a )

Do you have an option to change the kernel? It sounds like they have everything compiled in (no modules) and don't have the right support-

If it's a 3.xxx kernel it could be your os (if it's centos) iptables is also too old for the kernel.

rds100

@lpn said: sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

remove the MASQUERADE and use -j SNAT --to x.x.x.x

lsmod and depmod won't work on OpenVZ VPS, it's normal.

Also the iptables -L you did is wrong. Should have done iptables -t nat -L -n

Edit: if it's Xen you probably don't have the modules, need to download/compile them yourself. Who is the provider? Is there anything in their knowledgebase that talks about modules?

lpn

@rds100 said: @lpn said: sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

remove the MASQUERADE and use -j SNAT --to x.x.x.x

Would that work with dynamic IP addresses?

lsmod and depmod won't work on OpenVZ VPS, it's normal.

Also the iptables -L you did is wrong. Should have done iptables -t nat -L -n

thanks, that showed the rule

Edit: if it's Xen you probably don't have the modules, need to download/compile them yourself. Who is the provider? Is there anything in their knowledgebase that talks about modules?

will look at the KB later today

lpn

@unused said: What kernel are you using ( uname -a )

Do you have an option to change the kernel? It sounds like they have everything compiled in (no modules) and don't have the right support-

If it's a 3.xxx kernel it could be your os (if it's centos) iptables is also too old for the kernel.

3.8.4 on both Ubuntu and Debian; both 32 and 64 bit
Based on rds100's comment, it seems that the iptables rule is there, but for some reason it doesn't work as expected. I will look at what kind of modules can be enabled.

rds100

So if the rule is there and your VPN is still not working, can you please cat /proc/sys/net/ipv4/ip_forward and tell us what's the result?

lpn

@rds100 said: So if the rule is there and your VPN is still not working, can you please cat /proc/sys/net/ipv4/ip_forward and tell us what's the result?

It is 1, I have it set in sysctl.conf

lpn

As the issue is not what I thought it is, I will ask the moderators to close the thread and will post another one if I can't figure out the issue, which could be misconfiguration on the VPN server or client side

chasewalsh

instead of eth0, try venet0:

iptables -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to-source VPSIPADDRESS

lpn

@chasewalsh said: instead of eth0, try venet0:

iptables -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to-source VPSIPADDRESS

This is Xen, not OpenVZ

arieonline

it's solved?

lpn

@arieonline said: it's solved?

No, but it might be different issue than what I thought initially.