Stuart Henderson wrote:
> On 2006/12/28 03:20, Pontus Stenetorp wrote:
>> It seems that something fails with the tun/tap, but I am not sure what.
>> The owner of the VPN Server suggested that I'd use tap as an option
>> instead since OpenBSD should have a tap driver. I haven't been able to
>> Google forth any info on this and it seems that the howto;s approach
>> with tun is the correct one since OpenBSD has included tap-functionality
>> under tun.
>
> You need to use the tun device, with the link0 flag set on it (in
> /etc/hostname.tun0 or via ifconfig).
>
>
I have tried to do so, sorry about not mentioning it in the first mail.
I shall try to be more specific. This is my current status.
I am using
dev-type tap
dev tun0
which makes the tun0 device show up as an ethernet device and OpenVPN to
launch as intended.
I have set hostname.tun0 to
link0 up
and bridgename.bridge0 to
add 'int_iface'
add 'tun_iface'
up
I did a reboot in order to activate the bridge, this was stated at the
networking howto at openbsd.org. I haven't been able to launch OpenVPN
on boot however. This shouldn't be the issue, right?
After all this I expected packages from the internal network to flow to
the VPN Server. They do, but only if you specify the VPN Server IP,
otherwise they will use the normal route instead and ignore the tunnel.
I checked this using traceroute.
I couldn't change the default route at the GW but I changed so that the
route for the ip of www.whatismyip.org should be routed through the
OpenVPN server. Doing that caused whatismyip not to respond from my WS.
Leaving me curious why not all the traffic will be bridged and why the
OpenVPN Server won't do what I just think I told it to do.
Now I don't know how to proceed. How should I manage to force all
internet traffic oven the tunnel and do you agree with the OpenVPN
Server supplier that using tun screws this up(in my opinion tun should
work just as well when used properly)?
