Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Openvpn Port Forwarding Woes
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Openvpn Port Forwarding Woes

AlexJonesAlexJones Member
edited December 2017 in Help

Hi all, Im trying to port forward my openvpn vps server. Port 3074 Openvpn client ip 10.8.0.5
I have tried the following

iptables -t nat -A PREROUTING -i venet0 -d [publicip] -p tcp --dport 3074 -j DNAT --to-destination 10.8.0.5:3074

iptables -A FORWARD -p tcp --dport 3074 -j ACCEPT

iptables -t nat -A POSTROUTING -p tcp -d 10.8.0.5 --dport 3074 -j MASQUERADE

and

iptables -t nat -A PREROUTING -p tcp --dport 3074 -i venet0 -j DNAT --to-destination 10.8.0.5

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

iptables -I FORWARD -p tcp -i venet0 -d 10.8.0.5 --dport 3074 -j ACCEPT

I have tried both and while they report an open port, I cannot connect to BO2/3 servers.

Comments

  • Just a couple of thoughts:

    Do you really need MASQUERADE? Afaik SNAT is preferd when not dealing with a dynamic IP. From a quick look the second version looks better than the first (why would you specify an ip match for an interface that probably just has this single ip and why would you rewrite to a port thats already in the original packet? Is this even valid syntax?). Besides that the only thing that really strikes me is that there is no reverse forward rule as in nothing allows packets from tun0 back to venet0. Maybe try something like:

    iptables -A FORWARD -i tun0 -o venet0 -m state --state ESTABLISHED,RELATED -j ACCEPT

    If that does not help try to use LOG rules and tcpdump to see where your packets go wrong. Good luck.

    Thanked by 1WSS
  • AlexJonesAlexJones Member
    edited December 2017

    @mksh said:
    Just a couple of thoughts:

    Do you really need MASQUERADE? Afaik SNAT is preferd when not dealing with a dynamic IP. From a quick look the second version looks better than the first (why would you specify an ip match for an interface that probably just has this single ip and why would you rewrite to a port thats already in the original packet? Is this even valid syntax?). Besides that the only thing that really strikes me is that there is no reverse forward rule as in nothing allows packets from tun0 back to venet0. Maybe try something like:

    iptables -A FORWARD -i tun0 -o venet0 -m state --state ESTABLISHED,RELATED -j ACCEPT

    If that does not help try to use LOG rules and tcpdump to see where your packets go wrong. Good luck.

    I realized that the 2nd version isn't going to cut it because im on OVZ. I honestly don't know what to try at this point. I found a vpn port forwarding script and edited it to work and cleared csf firewall and it still won't work

  • mkshmksh Member
    edited December 2017

    @AlexJones said:
    I realized that the 2nd version isn't going to cut it because im on OVZ. I honestly don't know what to try at this point. I found a vpn port forwarding script and edited it to work and cleared csf firewall and it still won't work

    Ah, ok i never tried routing on OpenVZ so maybe there is some special requirements. Like i said you could try adding the line i posted to either to first or last version of your rules and see if it helps otherwise try to diagnose with LOG/tcpdump (Move your firewall rules out to custom chains and add log targets to see if they trigger. Have tcpdump listening on venet0 and tun0 to see if your packets show up there and in what state). Sorry, that's all the help i can offer remotely.

    Edit: Maybe check your routes too. I guess they are fine if OpenVpn works (as in you can reach the ports you are trying to forward from the box you are configuring iptables on) but that might cause it to fail too. And you have actually enabled forwarding, right (is this possible on OpenVZ?)?

  • @mksh said:

    @AlexJones said:
    I realized that the 2nd version isn't going to cut it because im on OVZ. I honestly don't know what to try at this point. I found a vpn port forwarding script and edited it to work and cleared csf firewall and it still won't work

    Ah, ok i never tried routing on OpenVZ so maybe there is some special requirements. Like i said you could try adding the line i posted to either to first or last version of your rules and see if it helps otherwise try to diagnose with LOG/tcpdump (Move your firewall rules out to custom chains and add log targets to see if they trigger. Have tcpdump listening on venet0 and tun0 to see if your packets show up there and in what state). Sorry, that's all the help i can offer remotely.

    Edit: Maybe check your routes too. I guess they are fine if OpenVpn works (as in you can reach the ports you are trying to forward from the box you are configuring iptables on) but that might cause it to fail too. And you have actually enabled forwarding, right (is this possible on OpenVZ?)?

    Idk its weird. If I port scan the ports show as open. But when trying to connect to BO2 etc. it won't work at all

  • You're on OpenVZ through a bridged, virtual interface. Things need to be done at the host level, much like TAP/TUN. You'd be better off just setting up OpenVPN under KVM. Since you seem to have a NAT running inside this- I assume you're running Virtuozzo intentionally, and have full control of the host node?

    Thanked by 2mksh AlexJones
  • mkshmksh Member
    edited December 2017

    @AlexJones said:
    Idk its weird. If I port scan the ports show as open. But when trying to connect to BO2 etc. it won't work at all

    I guess 'shows as open' implies you are getting an ACK back (better investigate with tcpdump). Last guess: Maybe it's MTU related? That sometimes leads to mysterious packetloss where tiny packets like the TCP handshake work fine but data packets just randomly disappear. Try lowering mtu on your tun interfaces (probably also on the other side of the vpn) to lets say 1000 and if that helps slowly work your way up torwards 1400 until it fails again.

    Edit: Got ninja'd. See above.

  • @WSS said:
    You're on OpenVZ through a bridged, virtual interface. Things need to be done at the host level, much like TAP/TUN. You'd be better off just setting up OpenVPN under KVM. Since you seem to have a NAT running inside this- I assume you're running Virtuozzo intentionally, and have full control of the host node?

    Unfortunately no. If I used the 2nd set of port forwarding rules (Masquerade) would I be successful on a kvm vps?

  • @AlexJones said:

    @WSS said:
    You're on OpenVZ through a bridged, virtual interface. Things need to be done at the host level, much like TAP/TUN. You'd be better off just setting up OpenVPN under KVM. Since you seem to have a NAT running inside this- I assume you're running Virtuozzo intentionally, and have full control of the host node?

    Unfortunately no. If I used the 2nd set of port forwarding rules (Masquerade) would I be successful on a kvm vps?

    Well, you'd have actual access to the virtual interface, so it'd make it easier to track down what isn't working. I came here to ask where are your 'return' rules, but then saw OVZ and said "Well it's already broken" to myself and went off to fuck elsewhere.

  • iptables -t nat -A PREROUTING -i venet0 -d [publicip] -p tcp --dport 3074 -j SNAT --to-destination 10.8.0.5

    Try that also don't forget you need to allow the TCP interface through your firewall as well.

  • @AuroraZ said:
    iptables -t nat -A PREROUTING -i venet0 -d [publicip] -p tcp --dport 3074 -j SNAT --to-destination 10.8.0.5

    Try that also don't forget you need to allow the TCP interface through your firewall as well.

    Iptables throws up errors about --to-destination

  • @AuroraZ said:
    iptables -t nat -A PREROUTING -i venet0 -d [publicip] -p tcp --dport 3074 -j SNAT --to-destination 10.8.0.5

    Try that also don't forget you need to allow the TCP interface through your firewall as well.

    Kernel 2.6.x dude.

  • @WSS said:

    @AuroraZ said:
    iptables -t nat -A PREROUTING -i venet0 -d [publicip] -p tcp --dport 3074 -j SNAT --to-destination 10.8.0.5

    Try that also don't forget you need to allow the TCP interface through your firewall as well.

    Kernel 2.6.x dude.

    Yeah I know his rules are wring or his values are one of the two. I have a shipload running in 2. 6... and never have used DNAT.

  • @AuroraZ said:

    @WSS said:

    @AuroraZ said:
    iptables -t nat -A PREROUTING -i venet0 -d [publicip] -p tcp --dport 3074 -j SNAT --to-destination 10.8.0.5

    Try that also don't forget you need to allow the TCP interface through your firewall as well.

    Kernel 2.6.x dude.

    Yeah I know his rules are wring or his values are one of the two. I have a shipload running in 2. 6... and never have used DNAT.

    I have never had good luck with lower level stuff and venet devices. That's why everything I deal with is now VirtIO or better.

Sign In or Register to comment.