If I were to hop by an intermediary server, I'd probably try to do with
NAT+forward only. Here is an untested IPtables version for the
intermediary/relay server:

iptables -t nat -A PREROUTING -s $STATIC_HOME_IP -p udp --dport 1194 \
                              -j DNAT --to my-openvpn-box
iptables -A FORWARD -s $STATIC_HOME_IP -d my-openvpn-box -p udp \
                    --dport 1194 -j ACCEPT
iptables -t nat -A POSTROUTING -d my-openvpn-box -p udp --dport 1194 \
                               -j MASQUERADE

HTH,
Simon


On 09/20/2015 02:58 PM, Marc Haber wrote:
> On Sun, Sep 20, 2015 at 08:45:20PM +0200, Gert Doering wrote:
>> On Sun, Sep 20, 2015 at 08:33:20PM +0200, Marc Haber wrote:
>>> $ socat -dd -T 86400 UDP4-RECVFROM:1194,fork 
>>> UDP4-DATAGRAM:my-openvpn-box:1194
>>>
>>> This unfortunately does not work as expected. socat seems to change
>>> the UDP source port of the relayed packets every once in a while. The
>>> OpenVPN serve does not like that.
>>
>> Fascinating.  Seems socat dies after a while, and when re-starting, it
>> gets a new port number...
> 
> ... and keeps its PID, which contradicts your "dies" assumption. I
> just guess that it's not geared to forward long lasting UDP
> communications.
> 
>> I have a solution for you, but you won't like it :-) - run git master
>> on the server, which has TLS floating, iow, if a client in good standing
>> starts sending packets from a new source address or new source port, 
>> the server will do TLS check on the packet, and if the packet verifies,
>> will just seamlessly move over to the new source ip+port combination.
>>
>> And yes, that means "bleeding edge!" - but the edge is somewhat blunt on 
>> this one, the change is in the tree since half a year, and I've been 
>> running it on production servers ever since.
> 
> I would still only do that als method of last resort if nothing else
> helps.
> 
>> Another option would be to just run a SOCKS proxy on the intermediate
>> box - you can use "--proto udp4 --socks-proxy $server $port" from
>> within OpenVPN.  "--proto udp6" *should* work, though I have not found
>> a SOCKS server yet that can actually do UDP+IPv6...  (ssh -D can do
>> IPv6, but only TCP...)
> 
> Socks will use TCP as tunnel transport, right? I would like to avoid
> that.
> 
> My tunnel is transported via IPv4, I use it to get IPv6 to my home. So
> SOCKS not running via IPv6 is not a big deal.
> 
> Greetings
> Marc
> 


------------------------------------------------------------------------------
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to