[lug] openvpn & linksys router question
Bear Giles
bgiles at coyotesong.com
Sat Jul 8 20:24:53 MDT 2006
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.)
More information about the LUG
mailing list