[lug] openvpn & linksys router question

[Bear Giles]

David L. Anselmi wrote:

> Bear Giles wrote:
>
>> I have a fairly standard setup - a home system behind a linksys 
>> router (and comcast) talking to an 'office'.  The linksys router is 
>> set up to forward the openvpn packets back to my system.
>
>
> So I'm not sure I follow you.  The VPN server is at home and the 
> client is at the office?  I assume that's what you mean if the linksys 
> at home is forwarding 1194 to a home machine.

Both systems are running openvpn. In this particular case it's P-t-P so 
there's not really a 'server' and 'client'.  I've also been 
experimenting with a true client/server model, but that just introduces 
some additional complications.

The 'office' is directly connected to the internet so it uses iptables 
as a software firewall.  New inbound UDP traffic is blocked so the 
firewall had to open port 1194 for openvpn connections.

The 'home' is connected via a linksys router/firewall.  In this case the 
firewall has to open port 1194 and forward the packets to the actual 
computer.

BTW, the vpn traffic is UDP packets with identical source and 
destination ports.

>> At first 'ping' from home to office fails.  tcpdump shows traffic on 
>> the home network, but not the office network, so I know the problem 
>> is on the outbound leg instead of the return.  Once I establish any 
>> type of VPN connection going the other way the stalled ping 
>> immediately succeeds.
>
>
> If you mean ping from home private network to office private network 
> doesn't work until the office sets up the VPN, that sounds to me like 
> just what you want.

It's P-t-P so either side should be able to initiate the connection.  
I'm not seeing that, only one side is able to initiate the connection.

>> hmmm... or it could still be a problem with the firewall on the 
>> 'office'.  I wouldn't see the network traffic if the firewall is 
>> still blocking that port.  But that firewall rule is stateless:
>>
>>   -A DEB-firewall-INPUT -p udp --dport 1194 -j ACCEPT
>
>
> So this rule looks like the firewall is the VPN server (and you need a 
> corresponding OUTPUT rule).


There's no output filtering on either side.  (Or shouldn't be.)