Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#612 closed Bug / Defect (invalid)

OpenVPN 2.3.8 topology subnet on FreeBSD 8.4 and 10.2 platform not normal operation

Reported by: hzdtony Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.8 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: topology
Cc:

Description

I have FreeBSD 8.4 from OpenVPN 2.3.6 update to 2.3.8, "topology subnet" not normal operation. I try on FreeBSD 10.2 platform install OpenVPN 2.3.8,same not normal operation. but complie openvpn 2.3.8Install and configure on ubuntu 14.0.4.3,and use same config file,topology subnet operation normal.Please confirm this problem.Thak a lot.

Change History (4)

comment:1 Changed 9 years ago by Gert Döring

Please explain (and show with a log file) what you mean with "not normal operation".

Our corporate VPN servers run FreeBSD with --topology subnet on FreeBSD 9.3 and 10.1, and the developers test on FreeBSD 7.4 to 10.2, and it works fine.

There was one change in OpenVPN 2.3.7 to fix trac #481 which changes the behaviour of OpenVPN on FreeBSD with topology subnet - but that is not in 2.3.6. So if it is not working for you both in 2.3.6 and 2.3.7, it is something else.

comment:2 Changed 8 years ago by Gert Döring

Resolution: invalid
Status: newclosed

If I can't get more details, I can't help. Closing this. Reopen if you are willing to provide more details and a log file.

comment:3 Changed 8 years ago by hzdtony

if use topology option, tun0 interface allocate one ip address,for example:
10.200.0.1 --> 10.200.0.1
but my tun0 interface allocate two ip address,for example:
10.200.0.1 --> 10.200.0.2
This why?

comment:4 Changed 8 years ago by Gert Döring

for correct operation, the tun0 interface needs to have different IP addresses for "local" and "remote" side (this is just how tun0 works) - so "10.100.0.1 -> 10.200.0.2" is right.

10.200.0.1 -> 10.200.0.1 will generally "work", but the machine itself will not respond to IP packets sent to its own address, 10.200.0.1, which is a problem on the server side - caused by the same address for local and remote side of the point-to-point interface.

(With topology subnet, the whole subnet will be routed to the tun0 interface in addition to the single address, so it does not technically matter *what* address is configured for "remote" - it needs to be something coming from the same subnet, but whether it is .2 or .5 or .254 on a /24 subnet has no relevance at all since no ARP is done here - it would make a difference on a BMA interface like ethernet)

Note: See TracTickets for help on using tickets.