Re: OpenVPN issues on 5.0
On Wed, Dec 28, 2011 at 08:02:54PM -0200, Christiano F. Haesbaert wrote: On Mon, Dec 26, 2011 at 08:57:18PM -0200, Christiano F. Haesbaert wrote: On Sun, Dec 25, 2011 at 04:10:19PM +0100, Erling Westenvik wrote: On Sat, Dec 24, 2011 at 07:50:53PM -0200, Christiano F. Haesbaert wrote: Heya, can you paste me the output of: ifconfig acx0 hwfeatures ifconfig url0 hwfeatures Sorry, but I'm not on -current. Are there other ways to display such information? Not like this, but I think I found your problem, could you please try the following diff: http://article.gmane.org/gmane.os.openbsd.misc/192013 If you have any problems applying it, please report to me off list. The diff fixes Erling's problem :). Confirmed! Thanks again! :)
Re: OpenVPN issues on 5.0
On Mon, Dec 26, 2011 at 08:57:18PM -0200, Christiano F. Haesbaert wrote: On Sun, Dec 25, 2011 at 04:10:19PM +0100, Erling Westenvik wrote: On Sat, Dec 24, 2011 at 07:50:53PM -0200, Christiano F. Haesbaert wrote: Heya, can you paste me the output of: ifconfig acx0 hwfeatures ifconfig url0 hwfeatures Sorry, but I'm not on -current. Are there other ways to display such information? Not like this, but I think I found your problem, could you please try the following diff: http://article.gmane.org/gmane.os.openbsd.misc/192013 If you have any problems applying it, please report to me off list. The diff fixes Erling's problem :).
Re: OpenVPN issues on 5.0
On Sun, Dec 25, 2011 at 04:10:19PM +0100, Erling Westenvik wrote: On Sat, Dec 24, 2011 at 07:50:53PM -0200, Christiano F. Haesbaert wrote: Heya, can you paste me the output of: ifconfig acx0 hwfeatures ifconfig url0 hwfeatures Sorry, but I'm not on -current. Are there other ways to display such information? Not like this, but I think I found your problem, could you please try the following diff: http://article.gmane.org/gmane.os.openbsd.misc/192013 If you have any problems applying it, please report to me off list.
Re: OpenVPN issues on 5.0
On Sat, Dec 24, 2011 at 07:50:53PM -0200, Christiano F. Haesbaert wrote: Heya, can you paste me the output of: ifconfig acx0 hwfeatures ifconfig url0 hwfeatures Sorry, but I'm not on -current. Are there other ways to display such information?
Re: OpenVPN issues on 5.0
Thanks. The last post on the thread of your supplied link, stated: when a packet comes from ral0 --- 10.0.0.1, the bridge changes the received interface to vr0, which has IFCAP_CSUM_IPv4. So when the icmp layer is about to test the checksum, it assumes the output interface is the same one which the packet came in (in our case, vr0, and not ral0). So the checksum does not get calculated. and that sounded familiar. On my attempts to analyze tcpdump(8) output from pf(4) on acx(4) and tun(4), I think (...) I noticed that packages received on acx were tagged as coming in on bge(4), not tun as I would expect. Am I understanding the potential problem correct? I believe my setup is a little different: WLAN | acx(4) -- tun(4) bridge bge(4) -- bge(4) url(4) -- INTERNET | LAN Fortunatly I still have the 5.0 machine available (I did the re-install with 4.7 on a different machine) but it is a laptop and I cannot replace bge. However, I can switch the setup and use either url(4, USB-adapter) or ep(4, PCMCIA) in place of bge, but I'm not sure if any of those won't do cksum offloading? ep1 == pcmcia1 3Com Corporation, 3C589, TP/BNC LAN Card Ver. 2a url0 == uhub0 port 1 USBKR100 USB 10/100 LAN rev 1.10/1.00 On Fri, Dec 23, 2011 at 05:26:07PM -0200, Christiano F. Haesbaert wrote: I didn't think this much through yet, but it can be a manifestation of: http://marc.info/?l=openbsd-miscm=132234363030132w=2 Could try replacing the bge with some cheap card, one that doesn't do cksum offloading ? If not, I'll check the driver to disable it this weekend. On 22 December 2011 21:32, Erling Westenvik erling.westen...@gmail.com wrote: On Thu, Dec 22, 2011 at 09:40:47AM +0100, Janne Johansson wrote: 2011/12/22 Erling Westenvik erling.westen...@gmail.com: Sorry for bumping this here @ misc when my question propably belong to some OpenVPN forum, but it seems like no-one out there can say much on OpenVPN issues that appears to be OpenBSD spesific. What puzzles me is that I cannot make the tun-interface show up in the route table on the server: DestinationGateway Flags Refs Use Mtu Prio Iface defaultAAA.BB.CCC.D UGS 3 1101 -8 url0 127/8 127.0.0.1 UGRS 00 331968 lo0 127.0.0.1 127.0.0.1 UH 20 331964 lo0 192.168.2/24 link#5UC 10 -4 acx0 192.168.2.200 00:16:ea:b3:65:d0 UHLc 1 400 -4 acx0 192.168.3/24 link#2UC 20 -4 bge0 192.168.3.106 00:1e:4f:95:19:1d UHLc 1 1582 -4 bge0 192.168.3.200 fe:e1:ba:d7:c3:24 UHLc 0 28 -4 bge0 193.90.160/20 link#6UC 10 -4 url0 AAA.BB.CCC.D 00:90:1a:42:6d:81 UHLc 10 -4 url0 AAA.BB.CCC.DDD 127.0.0.1 UGHS 00 331968 lo0 224/4 127.0.0.1 URS 00 331968 lo0 /etc/hostname.tun0 link0 up !/usr/local/sbin/openvpn --config /etc/openvpn/server.conf /etc/hostname.bridge0 add bge0 add acx0 up What does ifconfig tun0 say? When I did openvpn before I mostly didn't start openvpn from the tun config file myself, but rather start openvpn and make that one bring up tuns for me, but I would assume that if the tunnel goes up and then down and if it takes the tun0 down until the tunnel can be taken up again, the network that tun0 belonged to would not show in the routing table until it gets back up again. Any interface that has an address and that is up would somehow make an entry in the routing tables. Thanks, but I gave up, re-installed OpenBSD 4.7 and now everything is working. Beats me why but I'm pretty sure it had something to do with routing when running OpenVPN in bridged mode. For identical configurations as far as pf-, tun-, bridge- and OpenVPN files are concerned, this works: server: OpenBSD 4.7/OpenVPN 2.1.0 (using keys from 2.1.4) client: OpenBSD 5.0/OpenVPN 2.1.4 while this don't: server: OpenBSD 5.0/OpenVPN 2.1.4 client: OpenBSD 5.0/OpenVPN 2.1.4 I will try with OpenBSD 4.8 and 4.9 during the holidays. -- Cheers, Erling -- Cheers, Erling -- In terra pax hommnibus bonae voluntatis
Re: OpenVPN issues on 5.0
Solved! Or, since I don't really understand what is going on: solved.. I switched the roles for bge(4) and url(4) and all of a sudden everything started to work. I haven't tried to switch back to the non-working setup to verify, but please let me know if that would be of interest! Happy holidays! Cheers, Erling On Sat, Dec 24, 2011 at 12:32:00AM +0100, Erling Westenvik wrote: Thanks. The last post on the thread of your supplied link, stated: when a packet comes from ral0 --- 10.0.0.1, the bridge changes the received interface to vr0, which has IFCAP_CSUM_IPv4. So when the icmp layer is about to test the checksum, it assumes the output interface is the same one which the packet came in (in our case, vr0, and not ral0). So the checksum does not get calculated. and that sounded familiar. On my attempts to analyze tcpdump(8) output from pf(4) on acx(4) and tun(4), I think (...) I noticed that packages received on acx were tagged as coming in on bge(4), not tun as I would expect. Am I understanding the potential problem correct? I believe my setup is a little different: WLAN | acx(4) -- tun(4) bridge bge(4) -- bge(4) url(4) -- INTERNET | LAN Fortunatly I still have the 5.0 machine available (I did the re-install with 4.7 on a different machine) but it is a laptop and I cannot replace bge. However, I can switch the setup and use either url(4, USB-adapter) or ep(4, PCMCIA) in place of bge, but I'm not sure if any of those won't do cksum offloading? ep1 == pcmcia1 3Com Corporation, 3C589, TP/BNC LAN Card Ver. 2a url0 == uhub0 port 1 USBKR100 USB 10/100 LAN rev 1.10/1.00 On Fri, Dec 23, 2011 at 05:26:07PM -0200, Christiano F. Haesbaert wrote: I didn't think this much through yet, but it can be a manifestation of: http://marc.info/?l=openbsd-miscm=132234363030132w=2 Could try replacing the bge with some cheap card, one that doesn't do cksum offloading ? If not, I'll check the driver to disable it this weekend. On 22 December 2011 21:32, Erling Westenvik erling.westen...@gmail.com wrote: On Thu, Dec 22, 2011 at 09:40:47AM +0100, Janne Johansson wrote: 2011/12/22 Erling Westenvik erling.westen...@gmail.com: Sorry for bumping this here @ misc when my question propably belong to some OpenVPN forum, but it seems like no-one out there can say much on OpenVPN issues that appears to be OpenBSD spesific. What puzzles me is that I cannot make the tun-interface show up in the route table on the server: DestinationGateway Flags Refs Use Mtu Prio Iface defaultAAA.BB.CCC.D UGS 3 1101 -8 url0 127/8 127.0.0.1 UGRS 00 331968 lo0 127.0.0.1 127.0.0.1 UH 20 331964 lo0 192.168.2/24 link#5UC 10 -4 acx0 192.168.2.200 00:16:ea:b3:65:d0 UHLc 1 400 -4 acx0 192.168.3/24 link#2UC 20 -4 bge0 192.168.3.106 00:1e:4f:95:19:1d UHLc 1 1582 -4 bge0 192.168.3.200 fe:e1:ba:d7:c3:24 UHLc 0 28 -4 bge0 193.90.160/20 link#6UC 10 -4 url0 AAA.BB.CCC.D 00:90:1a:42:6d:81 UHLc 10 -4 url0 AAA.BB.CCC.DDD 127.0.0.1 UGHS 00 331968 lo0 224/4 127.0.0.1 URS 00 331968 lo0 /etc/hostname.tun0 link0 up !/usr/local/sbin/openvpn --config /etc/openvpn/server.conf /etc/hostname.bridge0 add bge0 add acx0 up What does ifconfig tun0 say? When I did openvpn before I mostly didn't start openvpn from the tun config file myself, but rather start openvpn and make that one bring up tuns for me, but I would assume that if the tunnel goes up and then down and if it takes the tun0 down until the tunnel can be taken up again, the network that tun0 belonged to would not show in the routing table until it gets back up again. Any interface that has an address and that is up would somehow make an entry in the routing tables. Thanks, but I gave up, re-installed OpenBSD 4.7 and now everything is working. Beats me why but I'm pretty sure it had something to do with routing when running OpenVPN in bridged mode. For identical configurations as far as pf-, tun-, bridge- and OpenVPN files are concerned, this works: server: OpenBSD 4.7/OpenVPN 2.1.0 (using keys from 2.1.4) client: OpenBSD 5.0/OpenVPN 2.1.4 while this don't: server: OpenBSD 5.0/OpenVPN 2.1.4 client: OpenBSD 5.0/OpenVPN 2.1.4 I will try with OpenBSD 4.8 and 4.9 during the holidays. -- Cheers, Erling -- Cheers, Erling -- In terra pax hommnibus bonae voluntatis
Re: OpenVPN issues on 5.0
2011/12/22 Erling Westenvik erling.westen...@gmail.com: Sorry for bumping this here @ misc when my question propably belong to some OpenVPN forum, but it seems like no-one out there can say much on OpenVPN issues that appears to be OpenBSD spesific. What puzzles me is that I cannot make the tun-interface show up in the route table on the server: DestinationGateway Flags Refs Use Mtu Prio Iface defaultAAA.BB.CCC.D UGS 3 1101 -8 url0 127/8 127.0.0.1 UGRS 00 331968 lo0 127.0.0.1 127.0.0.1 UH 20 331964 lo0 192.168.2/24 link#5UC 10 -4 acx0 192.168.2.200 00:16:ea:b3:65:d0 UHLc 1 400 -4 acx0 192.168.3/24 link#2UC 20 -4 bge0 192.168.3.106 00:1e:4f:95:19:1d UHLc 1 1582 -4 bge0 192.168.3.200 fe:e1:ba:d7:c3:24 UHLc 0 28 -4 bge0 193.90.160/20 link#6UC 10 -4 url0 AAA.BB.CCC.D 00:90:1a:42:6d:81 UHLc 10 -4 url0 AAA.BB.CCC.DDD 127.0.0.1 UGHS 00 331968 lo0 224/4 127.0.0.1 URS 00 331968 lo0 /etc/hostname.tun0 link0 up !/usr/local/sbin/openvpn --config /etc/openvpn/server.conf /etc/hostname.bridge0 add bge0 add acx0 up What does ifconfig tun0 say? When I did openvpn before I mostly didn't start openvpn from the tun config file myself, but rather start openvpn and make that one bring up tuns for me, but I would assume that if the tunnel goes up and then down and if it takes the tun0 down until the tunnel can be taken up again, the network that tun0 belonged to would not show in the routing table until it gets back up again. Any interface that has an address and that is up would somehow make an entry in the routing tables. -- To our sweethearts and wives. May they never meet. -- 19th century toast
Re: OpenVPN issues on 5.0
On Thu, Dec 22, 2011 at 09:40:47AM +0100, Janne Johansson wrote: 2011/12/22 Erling Westenvik erling.westen...@gmail.com: Sorry for bumping this here @ misc when my question propably belong to some OpenVPN forum, but it seems like no-one out there can say much on OpenVPN issues that appears to be OpenBSD spesific. What puzzles me is that I cannot make the tun-interface show up in the route table on the server: DestinationGateway Flags Refs Use Mtu Prio Iface defaultAAA.BB.CCC.D UGS 3 1101 -8 url0 127/8 127.0.0.1 UGRS 00 331968 lo0 127.0.0.1 127.0.0.1 UH 20 331964 lo0 192.168.2/24 link#5UC 10 -4 acx0 192.168.2.200 00:16:ea:b3:65:d0 UHLc 1 400 -4 acx0 192.168.3/24 link#2UC 20 -4 bge0 192.168.3.106 00:1e:4f:95:19:1d UHLc 1 1582 -4 bge0 192.168.3.200 fe:e1:ba:d7:c3:24 UHLc 0 28 -4 bge0 193.90.160/20 link#6UC 10 -4 url0 AAA.BB.CCC.D 00:90:1a:42:6d:81 UHLc 10 -4 url0 AAA.BB.CCC.DDD 127.0.0.1 UGHS 00 331968 lo0 224/4 127.0.0.1 URS 00 331968 lo0 /etc/hostname.tun0 link0 up !/usr/local/sbin/openvpn --config /etc/openvpn/server.conf /etc/hostname.bridge0 add bge0 add acx0 up What does ifconfig tun0 say? When I did openvpn before I mostly didn't start openvpn from the tun config file myself, but rather start openvpn and make that one bring up tuns for me, but I would assume that if the tunnel goes up and then down and if it takes the tun0 down until the tunnel can be taken up again, the network that tun0 belonged to would not show in the routing table until it gets back up again. Any interface that has an address and that is up would somehow make an entry in the routing tables. Thanks, but I gave up, re-installed OpenBSD 4.7 and now everything is working. Beats me why but I'm pretty sure it had something to do with routing when running OpenVPN in bridged mode. For identical configurations as far as pf-, tun-, bridge- and OpenVPN files are concerned, this works: server: OpenBSD 4.7/OpenVPN 2.1.0 (using keys from 2.1.4) client: OpenBSD 5.0/OpenVPN 2.1.4 while this don't: server: OpenBSD 5.0/OpenVPN 2.1.4 client: OpenBSD 5.0/OpenVPN 2.1.4 I will try with OpenBSD 4.8 and 4.9 during the holidays. -- Cheers, Erling
Re: OpenVPN issues on 5.0
On Wed, Dec 14, 2011 at 06:28:55PM -0800, Johan Beisser wrote: On Wed, Dec 14, 2011 at 5:54 PM, Erling Westenvik erling.westen...@gmail.com wrote: After upgrading (re-installing from scratch) my firewall from 4.6 (or 4.7) to 5.0, I have not been able to get OpenVPN back working. Please forgive me for asking here at misc but I have spent two days Googling, reading tons of HOWTO's and trying out different solutions, but without being able to solve the issue. What are your current pf.conf rules? Did you check that the syntax is right? Have you checked it for errors? Have you looked at the output for pflog? What's your current routing table? Does that look correct? I didn't dare to take Janne Johansson's little HOWTO Why a priori knowledge is better than HOWTO's as anything less than a challenge and have spent the last five days trying to learn adn understand some basic principles. Thank you, Janne. Really! Anyway, the problem was a combination of pf rules and routing tables. The former is solved completely and LAN clients and WLAN VPN-clients now connect with each other. But VPN clients cannot reach the server or the internet, and the server cannot reach the VPN clients. Sorry for bumping this here @ misc when my question propably belong to some OpenVPN forum, but it seems like no-one out there can say much on OpenVPN issues that appears to be OpenBSD spesific. What puzzles me is that I cannot make the tun-interface show up in the route table on the server: DestinationGateway Flags Refs Use Mtu Prio Iface defaultAAA.BB.CCC.D UGS 3 1101 -8 url0 127/8 127.0.0.1 UGRS 00 331968 lo0 127.0.0.1 127.0.0.1 UH 20 331964 lo0 192.168.2/24 link#5UC 10 -4 acx0 192.168.2.200 00:16:ea:b3:65:d0 UHLc 1 400 -4 acx0 192.168.3/24 link#2UC 20 -4 bge0 192.168.3.106 00:1e:4f:95:19:1d UHLc 1 1582 -4 bge0 192.168.3.200 fe:e1:ba:d7:c3:24 UHLc 0 28 -4 bge0 193.90.160/20 link#6UC 10 -4 url0 AAA.BB.CCC.D 00:90:1a:42:6d:81 UHLc 10 -4 url0 AAA.BB.CCC.DDD 127.0.0.1 UGHS 00 331968 lo0 224/4 127.0.0.1 URS 00 331968 lo0 /etc/hostname.tun0 link0 up !/usr/local/sbin/openvpn --config /etc/openvpn/server.conf /etc/hostname.bridge0 add bge0 add acx0 up -- Cheers, Erling
Re: OpenVPN issues on 5.0
2011/12/16 Erling Westenvik erling.westen...@gmail.com Links to foolproof HOWTO's will be much appreciated! Nature has thwarted all attempts to make such HOWTOs by make ever better fools, which probably is why you: ...but I have spent two days Googling, reading tons of HOWTO's and trying out different solutions, but without being able to solve the issue. Not to say you are a fool, but HOWTOs for anything else than the most simple stuff can't cover all cases, which means you still must understand things or the HOWTO will not help you and instead lead you astray in the wrong direction, making you look foolish when you in reality wanted help. In the long run, learning the stuff you attempt to do instead of wasting two days following someone elses bad advice is better spent. -- To our sweethearts and wives. May they never meet. -- 19th century toast
Re: OpenVPN issues on 5.0
On 2011-12-16, Erling Westenvik erling.westen...@gmail.com wrote:
11 antispoof quick for {lo,$int,$wap,$vpn}
this may well not be helping.
Re: OpenVPN issues on 5.0
On 15/12/11 03:54, Erling Westenvik wrote: PROBLEM: Clients successfully connect to VPN server, receive proper dhcp addresses for both wlan and tunnel interfaces (and can reach the wlan subnet) but fail to reach the wired lan or internet. /var/log/messages indicates everything is up and running. Sometimes the problem is on the client side and not the server side. For instance, in Windows Vista and Windows 7 openvpn must be started as administrator (right click) otherwise the program does not have access to add the routing rules in the routing table. Clients looks like it was successfully connected but after a while disconnects cause nothing is passed through the tunnel. Giannis
Re: OpenVPN issues on 5.0
On Thu, Dec 15, 2011 at 03:59:29AM +0100, Erling Westenvik wrote: On Wed, Dec 14, 2011 at 06:28:55PM -0800, Johan Beisser wrote: On Wed, Dec 14, 2011 at 5:54 PM, Erling Westenvik erling.westen...@gmail.com wrote: After upgrading (re-installing from scratch) my firewall from 4.6 (or 4.7) to 5.0, I have not been able to get OpenVPN back working. Please forgive me for asking here at misc but I have spent two days Googling, reading tons of HOWTO's and trying out different solutions, but without being able to solve the issue. What are your current pf.conf rules? Did you check that the syntax is right? Have you checked it for errors? Have you looked at the output for pflog? What's your current routing table? Does that look correct? pf.conf should be ok. It is the same as it was under the previously working setup. Given the significant changed to pf and pf.conf syntax in recent years this is not a safe assumption. Not knowing exactly where you started from it's hard to say exactly. Ken
Re: OpenVPN issues on 5.0
I'm running OpenBSD on eight machines here, from version 4.6 on one of
them and version 4.9 and 5.0 on the rest, so I am quite used to
different PF syntax. That being said: I have really only limited
understanding of routing tables and other heavy technical stuff, but
I'm stubborn and usually get along without having to bother people with
too many stupid questions. But this time I'm lost...
Below is my (somewhat simplified) pf.conf:
1 ext = url0
2 int = bge0
3 wap = acx0 (wireless access point)
4 vpn = tun0
5 match out on $ext inet from !($ext) to any nat-to ($ext:0)
6 block log all
7 pass out on $ext
8 passon $wap proto icmp all icmp-type 8 keep state
9 pass log on $wap proto udp from any to any port 1194 keep state
10 pass log quick on {lo,$int,$vpn}
11 antispoof quick for {lo,$int,$wap,$vpn}
My guess is that the problem has got something to do with routing. Here
is route show from the server:
DestinationGatewayFlags Refs Use Mtu Prio Iface
defaultc01A05AC1.dhcp.blu UGS323562 - 8 url0
loopback localhost UGRS 00 33196 8 lo0
localhost localhost UH 2 86 33196 4 lo0
192.168.2/24 link#5 UC 10 - 4 acx0
192.168.2.200 00:16:ea:b3:65:d0 UHLc 1 976 - 4 acx0
192.168.3/24 link#2 UC 30 - 4 bge0
192.168.3.100:14:c2:e1:ad:6f UHLc 0 16 - 4 lo0
192.168.3.101 fe:e1:ba:d0:d3:63 UHLc 0 147 - 4 bge0
192.168.3.106 00:1e:4f:95:19:1d UHLc 245224 - 4 bge0
c00A05AC1.dhcp.blu link#6 UC 20 - 4 url0
c01A05AC1.dhcp.blu 00:90:1a:42:6d:81 UHLc 2 133 - 4 url0
c96A45AC1.dhcp.blu localhost UGHS 00 33196 8 lo0
c5FAC5AC1.dhcp.blu 00:90:1a:42:6d:81 UHLc 04 - 4 url0
BASE-ADDRESS.MCAST localhost URS00 33196 8 lo0
But I also guess that I'm neither describing my problem very good, nor
asking the right questions. Links to foolproof HOWTO's will be much
appreciated!
Regards,
Erling
On Thu, Dec 15, 2011 at 08:27:13AM -0500, Kenneth R Westerback wrote:
On Thu, Dec 15, 2011 at 03:59:29AM +0100, Erling Westenvik wrote:
On Wed, Dec 14, 2011 at 06:28:55PM -0800, Johan Beisser wrote:
On Wed, Dec 14, 2011 at 5:54 PM, Erling Westenvik
erling.westen...@gmail.com wrote:
After upgrading (re-installing from scratch) my firewall from 4.6 (or
4.7) to 5.0, I have not been able to get OpenVPN back working. Please
forgive me for asking here at misc but I have spent two days Googling,
reading tons of HOWTO's and trying out different solutions, but without
being able to solve the issue.
What are your current pf.conf rules? Did you check that the syntax is
right? Have you checked it for errors? Have you looked at the output
for pflog?
What's your current routing table? Does that look correct?
pf.conf should be ok. It is the same as it was under the previously
working setup.
Given the significant changed to pf and pf.conf syntax in recent years
this is not a safe assumption. Not knowing exactly where you started
from it's hard to say exactly.
Ken
--
Regards,
Erling
-- In terra pax hommnibus bonae voluntatis
OpenVPN issues on 5.0
After upgrading (re-installing from scratch) my firewall from 4.6 (or 4.7) to 5.0, I have not been able to get OpenVPN back working. Please forgive me for asking here at misc but I have spent two days Googling, reading tons of HOWTO's and trying out different solutions, but without being able to solve the issue. The previous and working implementation were based on this HOWTO, http://personal.exadios.com/Technical/IEEE802.11/a0001.html, which worked well in describing how to bridge a wired lan with a wireless lan. PROBLEM: Clients successfully connect to VPN server, receive proper dhcp addresses for both wlan and tunnel interfaces (and can reach the wlan subnet) but fail to reach the wired lan or internet. /var/log/messages indicates everything is up and running. CURRENT SETUP: Interfaces on firewall/vpn server: url0 - dhcp NONE NONE NONE (isp) acx0 - inet 192.168.2.1 255.255.255.0 NONE (wlan accesspoint) tun0 - link0\up bridge0 - add bge0\add tun0\up bge0 - inet 192.168.3.1 255.255.255.0 NONE (lan) /etc/openvpn/server.conf ---8--- daemon openvpn writepid /var/openvpn/pid status /var/openvpn/status 10 local 192.168.2.1 port 1194 proto udp dev tun0 dev-type tap client-to-client ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key dh /etc/openvpn/keys/dh1024.pem server-bridge 192.168.3.1 255.255.255.0 192.168.3.200 192.168.3.210 # change to your setup ifconfig-pool-persist /var/openvpn/ipp.txt push redirect-gateway local def1 #push redirect-gateway 192.168.3.1 keepalive 10 120 tls-auth /etc/openvpn/keys/ta.key 0 cipher BF-CBC # Blowfish (default) max-clients 10 user _openvpn group _openvpn persist-key persist-tun verb 3 mute 20 chroot /var/empty ---8--- Interfaces on client machine/vpn client: iwn0 - dhcp NONE NONE NONE [wlan options] tun0 - link0\up /etc/openvpn/client.conf ---8--- client dev tun0 dev-type tap proto udp remote 192.168.2.1 port 1194 resolv-retry infinite nobind user _openvpn group _openvpn persist-key persist-tun mute-replay-warnings ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/client.crt key /etc/openvpn/keys/client.key ns-cert-type server tls-auth /etc/openvpn/keys/ta.key 1 cipher BF-CBC verb 3 mute 20 chroot /var/empty ---8--- /etc/resolv.conf ---8--- nameserver 192.168.3.1 nameserver 193.75.75.75 nameserver 193.75.75.193 lookup file bind ---8--- A tcpdump on acx0 (wlan accesspont) yields this: ---8--- # tcpdump -env -ttt -i acx0 tcpdump: listening on acx0, link-type EN10MB Dec 15 02:15:35.159695 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 375: 192.168.2.1.1194 192.168.2.200.42941: udp 333 (ttl 64, id 41258, len 361) Dec 15 02:15:35.159822 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 391: 192.168.2.1.1194 192.168.2.200.42941: udp 349 (ttl 64, id 5887, len 377) Dec 15 02:15:35.159914 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 431: 192.168.2.1.1194 192.168.2.200.42941: udp 389 (ttl 64, id 58840, len 417) Dec 15 02:15:35.160033 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 447: 192.168.2.1.1194 192.168.2.200.42941: udp 405 (ttl 64, id 56154, len 433) Dec 15 02:15:35.160122 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 439: 192.168.2.1.1194 192.168.2.200.42941: udp 397 (ttl 64, id 32655, len 425) Dec 15 02:15:35.161985 00:16:ea:b3:65:d0 00:0f:3d:58:b5:00 0800 95: 192.168.2.200.42941 192.168.2.1.1194: [udp sum ok] udp 53 (ttl 64, id 4108, len 81) Dec 15 02:15:35.346095 00:16:ea:b3:65:d0 00:0f:3d:58:b5:00 0800 151: 192.168.2.200.42941 192.168.2.1.1194: udp 109 (ttl 64, id 51891, len 137) Dec 15 02:15:35.346276 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 151: 192.168.2.1.1194 192.168.2.200.42941: udp 109 (ttl 64, id 2, len 137) Dec 15 02:15:40.355711 00:16:ea:b3:65:d0 00:0f:3d:58:b5:00 0800 72: 192.168.2.200.29597 193.75.75.75.53: [udp sum ok] 53793+ A? pool.ntp.org. (30) (ttl 64, id 39342, len 58) ---8--- However, a tcpdump on tun0 on the OpenVPN server yields the following: ---8--- # tcpdump -env -ttt -i tun0 tcpdump: listening on tun0, link-type EN10MB Dec 15 02:12:00.945266 fe:e1:ba:da:9e:7a 00:14:c2:e1:ad:6f 0800 72: 192.168.3.200.37441 192.168.3.1.53: [udp sum ok] 10028+ ? pool.ntp.org. (30) (ttl 64, id 50329, len 58) Dec 15 02:12:00.945311 00:14:c2:e1:ad:6f fe:e1:ba:da:9e:7a 0800 70: 192.168.3.1 192.168.3.200: icmp: 192.168.3.1 udp port 53 unreachable (ttl 255, id 42537, len 56, bad cksum 0!) Dec 15 02:12:03.915356 fe:e1:ba:da:9e:7a 00:14:c2:e1:ad:6f 0800 79: 192.168.3.200.27617 192.168.3.1.53: [udp sum ok] 64252+ ? fxfeeds.mozilla.com. (37) (ttl 64, id 8802, len 65) Dec 15 02:12:03.915387 00:14:c2:e1:ad:6f fe:e1:ba:da:9e:7a 0800 70: 192.168.3.1 192.168.3.200: icmp: 192.168.3.1 udp port 53 unreachable (ttl 255, id 5606, len 56, bad cksum 0!) ---8--- Thanks in advance, Erling Westenvik
Re: OpenVPN issues on 5.0
On Wed, Dec 14, 2011 at 5:54 PM, Erling Westenvik erling.westen...@gmail.com wrote: After upgrading (re-installing from scratch) my firewall from 4.6 (or 4.7) to 5.0, I have not been able to get OpenVPN back working. Please forgive me for asking here at misc but I have spent two days Googling, reading tons of HOWTO's and trying out different solutions, but without being able to solve the issue. What are your current pf.conf rules? Did you check that the syntax is right? Have you checked it for errors? Have you looked at the output for pflog? What's your current routing table? Does that look correct?
Re: OpenVPN issues on 5.0
On Wed, Dec 14, 2011 at 06:28:55PM -0800, Johan Beisser wrote: On Wed, Dec 14, 2011 at 5:54 PM, Erling Westenvik erling.westen...@gmail.com wrote: After upgrading (re-installing from scratch) my firewall from 4.6 (or 4.7) to 5.0, I have not been able to get OpenVPN back working. Please forgive me for asking here at misc but I have spent two days Googling, reading tons of HOWTO's and trying out different solutions, but without being able to solve the issue. What are your current pf.conf rules? Did you check that the syntax is right? Have you checked it for errors? Have you looked at the output for pflog? What's your current routing table? Does that look correct? pf.conf should be ok. It is the same as it was under the previously working setup. Everything on my wired lan (192.168.3.0) is working, and wireless clients (192.168.2.0) get dhcp addresses both for their wlan- interface as well as for their tun-interface. I have tried with pass quick-rules for the latter interfaces but with no difference. Pinging the accesspoint (192.168.2.1) from a wireless client, works. As for routing tables I'm quite a noob and I have been wondering if everything could be about the bridge0-interface? # route show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultc01A05AC1.dhcp.blu UGS 3 20949 -8 url0 loopback localhost UGRS 0 0 331968 lo0 localhost localhost UH 286 331964 lo0 192.168.2/24 link#5 UC 1 0 -4 acx0 192.168.2.200 00:16:ea:b3:65:d0 UHLc 1 1129 -4 acx0 192.168.3/24 link#2 UC 2 0 -4 bge0 192.168.3.106 00:1e:4f:95:19:1d UHLc 1 24936 -4 bge0 192.168.3.200 fe:e1:ba:da:9e:7a UHLc 0 401 -4 bge0 c00A05AC1.dhcp.blu link#6 UC 2 0 -4 url0 c01A05AC1.dhcp.blu 00:90:1a:42:6d:81 UHLc 2 113 -4 url0 c96A45AC1.dhcp.blu localhost UGHS 0 0 331968 lo0 c5FAC5AC1.dhcp.blu 00:90:1a:42:6d:81 UHLc 0 4 -4 url0 BASE-ADDRESS.MCAST localhost URS 0 0 331968 lo0 Regards, Erling
Re: OpenVPN issues on 5.0
Yeah, net.inet.ip.forwarding=1, but thanks. I should perhaps have made it more clear that my wired lan (192.168.3.0) works normally -- and my wireless too when without OpenVPN. I'm feeling quite stupid here, being more and more certain that the solution is very close. And very simple... On Wed, Dec 14, 2011 at 11:02:43PM -0500, Josh Grosse wrote: Erling Westenvik erling.westen...@gmail.com wrote: After upgrading (re-installing from scratch) my firewall from 4.6 (or 4.7) to 5.0, I have not been able to get OpenVPN back working. Please forgive me for asking here at misc but I have spent two days Googling, reading tons of HOWTO's and trying out different solutions, but without being able to solve the issue. The previous and working implementation were based on this HOWTO, http://personal.exadios.com/Technical/IEEE802.11/a0001.html, which worked well in describing how to bridge a wired lan with a wireless lan. PROBLEM: Clients successfully connect to VPN server, receive proper dhcp addresses for both wlan and tunnel interfaces (and can reach the wlan subnet) but fail to reach the wired lan or internet. /var/log/messages indicates everything is up and running. CURRENT SETUP: Interfaces on firewall/vpn server: url0 - dhcp NONE NONE NONE (isp) acx0 - inet 192.168.2.1 255.255.255.0 NONE (wlan accesspoint) tun0 - link0\up bridge0 - add bge0\add tun0\up bge0 - inet 192.168.3.1 255.255.255.0 NONE (lan) /etc/openvpn/server.conf ---8--- daemon openvpn writepid /var/openvpn/pid status /var/openvpn/status 10 local 192.168.2.1 port 1194 proto udp dev tun0 dev-type tap client-to-client ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key dh /etc/openvpn/keys/dh1024.pem server-bridge 192.168.3.1 255.255.255.0 192.168.3.200 192.168.3.210 # change to your setup ifconfig-pool-persist /var/openvpn/ipp.txt push redirect-gateway local def1 #push redirect-gateway 192.168.3.1 keepalive 10 120 tls-auth /etc/openvpn/keys/ta.key 0 cipher BF-CBC # Blowfish (default) max-clients 10 user _openvpn group _openvpn persist-key persist-tun verb 3 mute 20 chroot /var/empty ---8--- Interfaces on client machine/vpn client: iwn0 - dhcp NONE NONE NONE [wlan options] tun0 - link0\up /etc/openvpn/client.conf ---8--- client dev tun0 dev-type tap proto udp remote 192.168.2.1 port 1194 resolv-retry infinite nobind user _openvpn group _openvpn persist-key persist-tun mute-replay-warnings ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/client.crt key /etc/openvpn/keys/client.key ns-cert-type server tls-auth /etc/openvpn/keys/ta.key 1 cipher BF-CBC verb 3 mute 20 chroot /var/empty ---8--- /etc/resolv.conf ---8--- nameserver 192.168.3.1 nameserver 193.75.75.75 nameserver 193.75.75.193 lookup file bind ---8--- A tcpdump on acx0 (wlan accesspont) yields this: ---8--- # tcpdump -env -ttt -i acx0 tcpdump: listening on acx0, link-type EN10MB Dec 15 02:15:35.159695 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 375: 192.168.2.1.1194 192.168.2.200.42941: udp 333 (ttl 64, id 41258, len 361) Dec 15 02:15:35.159822 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 391: 192.168.2.1.1194 192.168.2.200.42941: udp 349 (ttl 64, id 5887, len 377) Dec 15 02:15:35.159914 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 431: 192.168.2.1.1194 192.168.2.200.42941: udp 389 (ttl 64, id 58840, len 417) Dec 15 02:15:35.160033 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 447: 192.168.2.1.1194 192.168.2.200.42941: udp 405 (ttl 64, id 56154, len 433) Dec 15 02:15:35.160122 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 439: 192.168.2.1.1194 192.168.2.200.42941: udp 397 (ttl 64, id 32655, len 425) Dec 15 02:15:35.161985 00:16:ea:b3:65:d0 00:0f:3d:58:b5:00 0800 95: 192.168.2.200.42941 192.168.2.1.1194: [udp sum ok] udp 53 (ttl 64, id 4108, len 81) Dec 15 02:15:35.346095 00:16:ea:b3:65:d0 00:0f:3d:58:b5:00 0800 151: 192.168.2.200.42941 192.168.2.1.1194: udp 109 (ttl 64, id 51891, len 137) Dec 15 02:15:35.346276 00:0f:3d:58:b5:00 00:16:ea:b3:65:d0 0800 151: 192.168.2.1.1194 192.168.2.200.42941: udp 109 (ttl 64, id 2, len 137) Dec 15 02:15:40.355711 00:16:ea:b3:65:d0 00:0f:3d:58:b5:00 0800 72: 192.168.2.200.29597 193.75.75.75.53: [udp sum ok] 53793+ A? pool.ntp.org. (30) (ttl 64, id 39342, len 58) ---8--- However, a tcpdump on tun0 on the OpenVPN server yields the following: ---8--- # tcpdump -env -ttt -i tun0 tcpdump: listening on tun0, link-type EN10MB Dec 15 02:12:00.945266 fe:e1:ba:da:9e:7a 00:14:c2:e1:ad:6f 0800 72: 192.168.3.200.37441 192.168.3.1.53: [udp sum ok] 10028+ ? pool.ntp.org. (30) (ttl 64, id 50329, len 58) Dec 15 02:12:00.945311 00:14:c2:e1:ad:6f fe:e1:ba:da:9e:7a 0800 70: 192.168.3.1 192.168.3.200: icmp: 192.168.3.1 udp port 53 unreachable (ttl 255, id 42537, len 56, bad cksum 0!) Dec 15 02:12:03.915356 fe:e1:ba:da:9e:7a 00:14:c2:e1:ad:6f 0800 79: 192.168.3.200.27617
