OpenVPN
Hello all.* I had introduced myself a few weeks ago and mentioned that I have some OpenVPN experience.* Today I was reading over some of the SOPs and noticed this TODO on the OpenVPN SOP:
---- Deploy an additional VPN server outside of PHX. OpenVPN does support failover automatically so if configured properly, when the primary VPN server goes down all hosts should connect to the next host in the list ---- I would like to offer to work on this.* I would need a mentor to help me get acclimated to the environment but I am confident that I could get it up and running effectively and I have some spare time that I would love to put towards this. Regards. -- TJ Davis The sun can still shine behind a closed mind. *-All Together Separate _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list |
OpenVPN
On Wed, 10 Dec 2008, TJ Davis wrote:
> Hello all.* I had introduced myself a few weeks ago and mentioned that I have some OpenVPN experience.* Today I was > reading over some of the SOPs and noticed this TODO on the OpenVPN SOP: > > ---- > Deploy an additional VPN server outside of PHX. OpenVPN does support failover automatically so if configured properly, > when the primary VPN server goes down all hosts should connect to the next host in the list > ---- > > I would like to offer to work on this.* I would need a mentor to help me get acclimated to the environment but I am > confident that I could get it up and running effectively and I have some spare time that I would love to put towards > this. > > Regards. > > -- > TJ Davis Sounds good TJ, Ricky was working on this a bit but he's also pretty busy. Stop by #fedora-admin sometime tomorrow and ping me, we'll put a plan together. -Mike______________________________________________ _ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list |
OpenVPN
On 2008-12-10 05:30:44 PM, Mike McGrath wrote:
> Sounds good TJ, Ricky was working on this a bit but he's also pretty busy. > Stop by #fedora-admin sometime tomorrow and ping me, we'll put a plan > together. Cool, I'd definitely love to discuss some methods for how we'd setup a failover for our current single VPN machine. By the way, building vpn2 was blocking on an IP from ibiblio - did we get that? Thanks, Ricky _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list |
OpenVPN
On Thu, 11 Dec 2008, Ricky Zhou wrote:
> On 2008-12-10 05:30:44 PM, Mike McGrath wrote: > > Sounds good TJ, Ricky was working on this a bit but he's also pretty busy. > > Stop by #fedora-admin sometime tomorrow and ping me, we'll put a plan > > together. > Cool, I'd definitely love to discuss some methods for how we'd setup a > failover for our current single VPN machine. > > By the way, building vpn2 was blocking on an IP from ibiblio - did we > get that? > Yep: vpn2.fedoraproject.org 152.46.7.226 -Mike _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list |
OpenVPN
Hi all!
I was making a first attempt to establish a VPN between my house and the office. The scenery from the side of my house is the following one: ________ +----------+ +-----------+ +----------+ ____/ \___ | OpenVPN |_____| GNU/Linux |_____| ADSL |_____/ Internet | server | | Firewall | | Router | \____ ____/ +----------+ +-----------+ +----------+ \_______/ Local network: 10.1.0.0/24 VPN network: 10.8.0.0/24 In the GNU/Linux firewall configuration (using Shorewall), I only added a DNAT rule to the OpenVPN server. I believe that it is the unique thing that it would be being necessary. Besides this, in router I added a rule doing forwarding of the originating traffic of its own WAN with port 1194 to the interface that it has in the other end that it gives with GNU/Linux firewall. Until this instance, starting a OpenVPN client in the office I could verify that the tunnel is established, but I can only reach the OpenVPN server. The rest of hosts of my LAN is unareachables. The following one is a capture with tcpump in the OpenVPN server when I doing ping from the office to one host of my house: # tcpdump -i tun0 tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 07:08:17.231084 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 47698, seq 1, length 64 07:08:18.233021 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 47698, seq 2, length 64 07:08:19.231793 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 47698, seq 3, length 64 Apparently it would be lacking some way that causes that the packages could return. Then I tried adding the following thing: * To add in my GNU/Linux firewall a rule so that all the traffic that goes to the network 10.8.0.0/24 is reached through the IP of the OpenVPN server: # route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.1.0.4 * Enable forwarding in the OpenVPN server: # echo 1 > /proc/sys/net/ipv4/ip_forward And I repeated the test: 07:13:17.213590 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 55380, seq 1, length 64 07:13:17.213942 IP ns1.freesoftware.org > 10.8.0.6: ICMP echo reply, id 55380, seq 1, length 64 07:13:18.215097 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 55380, seq 2, length 64 07:13:18.215433 IP ns1.freesoftware.org > 10.8.0.6: ICMP echo reply, id 55380, seq 2, length 64 07:13:19.215920 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 55380, seq 3, length 64 07:13:19.216272 IP ns1.freesoftware.org > 10.8.0.6: ICMP echo reply, id 55380, seq 3, length 64 This way already I could reach with ping/nmap at the other hosts from the network. But in tests that I was doing there are moments at which when trying to login using ssh I can get it and in others I cannot. In this second case, tcpdump showed a similar problem to which commented above. I have the impression that continues existing some routing problem somewhere. Some idea of what can be the problem? Thanks in advance for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Squeeze - Linux user #188.598 |
OpenVPN
Daniel,
> Until this instance, starting a OpenVPN client in the office I could > verify that the tunnel is established, but I can only reach the OpenVPN > server. The rest of hosts of my LAN is unareachables. > ... > I have the impression that continues existing some routing problem > somewhere. Some idea of what can be the problem? For a few years now I've run a VPN similar to what you describe. http://carnot.yi.org/NetworksPage.html Observe entries such as "route 172.23.4.2" and "# route shawmail.gv.shawcable.net" in dalton: ... myvpn.conf. "route 172.23.4.2" allows a machine such as Cantor at UBC to transmit to Curie at home. "route shawmail.gv.shawcable.net" allows Cantor at UBC to send a message through the tunnel to the SMTP server of my home ISP. The server will not accept the message unless it comes from my LAN. With this routing, the UBC and home LANs are in effect one LAN. The domain name for SMTP is associated with two IP addresses. For routing to be reliable, both addresses must specified explicitly. Shorewall is a superb example of open source software. Documentation is excellent. Regards, ... Peter E. -- Google "pathology workshop" -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
OpenVPN
Daniel,
Second copy of this reply. I forgot the In-reply-to address in the first. > Until this instance, starting a OpenVPN client in the office I could > verify that the tunnel is established, but I can only reach the OpenVPN > server. The rest of hosts of my LAN is unareachables. > ... > I have the impression that continues existing some routing problem > somewhere. Some idea of what can be the problem? For a few years now I've run a VPN similar to what you describe. http://carnot.yi.org/NetworksPage.html Observe entries such as "route 172.23.4.2" and "# route shawmail.gv.shawcable.net" in dalton: ... myvpn.conf. "route 172.23.4.2" allows a machine such as Cantor at UBC to transmit to Curie at home. "route shawmail.gv.shawcable.net" allows Cantor at UBC to send a message through the tunnel to the SMTP server of my home ISP. The server will not accept the message unless it comes from my LAN. With this routing, the UBC and home LANs are in effect one LAN. The domain name for SMTP is associated with two IP addresses. For routing to be reliable, both addresses must specified explicitly. Shorewall is a superb example of open source software. Documentation is excellent. Regards, ... Peter E. -- Google "pathology workshop" -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
OpenVPN
On Wed, Oct 28, 2009 at 06:24:05AM -0300, Daniel Bareiro wrote:
> > Hi all! > > I was making a first attempt to establish a VPN between my house and the > office. The scenery from the side of my house is the following one: > ________ > +----------+ +-----------+ +----------+ ____/ \___ > | OpenVPN |_____| GNU/Linux |_____| ADSL |_____/ Internet > | server | | Firewall | | Router | \____ ____/ > +----------+ +-----------+ +----------+ \_______/ > > Local network: 10.1.0.0/24 > VPN network: 10.8.0.0/24 any particular reason not to run the vpn server on the firewall ! it is already the default gw for your local lan and it would make routing easier. what you have below is the a sympton of the routing problem. also any reason you choose tun over tap - I usually default to tap. Alex > > In the GNU/Linux firewall configuration (using Shorewall), I only added a > DNAT rule to the OpenVPN server. I believe that it is the unique thing that > it would be being necessary. > > Besides this, in router I added a rule doing forwarding of the > originating traffic of its own WAN with port 1194 to the interface that > it has in the other end that it gives with GNU/Linux firewall. > > Until this instance, starting a OpenVPN client in the office I could > verify that the tunnel is established, but I can only reach the OpenVPN > server. The rest of hosts of my LAN is unareachables. > > The following one is a capture with tcpump in the OpenVPN server when I > doing ping from the office to one host of my house: > > # tcpdump -i tun0 > tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes > 07:08:17.231084 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 47698, seq 1, length 64 > 07:08:18.233021 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 47698, seq 2, length 64 > 07:08:19.231793 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 47698, seq 3, length 64 > > Apparently it would be lacking some way that causes that the packages > could return. > > Then I tried adding the following thing: > > * To add in my GNU/Linux firewall a rule so that all the traffic that > goes to the network 10.8.0.0/24 is reached through the IP of the > OpenVPN server: > > # route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.1.0.4 > > * Enable forwarding in the OpenVPN server: > > # echo 1 > /proc/sys/net/ipv4/ip_forward > > And I repeated the test: > > 07:13:17.213590 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 55380, seq 1, length 64 > 07:13:17.213942 IP ns1.freesoftware.org > 10.8.0.6: ICMP echo reply, id 55380, seq 1, length 64 > 07:13:18.215097 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 55380, seq 2, length 64 > 07:13:18.215433 IP ns1.freesoftware.org > 10.8.0.6: ICMP echo reply, id 55380, seq 2, length 64 > 07:13:19.215920 IP 10.8.0.6 > ns1.freesoftware.org: ICMP echo request, id 55380, seq 3, length 64 > 07:13:19.216272 IP ns1.freesoftware.org > 10.8.0.6: ICMP echo reply, id 55380, seq 3, length 64 > > This way already I could reach with ping/nmap at the other hosts from the > network. But in tests that I was doing there are moments at which when > trying to login using ssh I can get it and in others I cannot. In this > second case, tcpdump showed a similar problem to which commented above. > > I have the impression that continues existing some routing problem > somewhere. Some idea of what can be the problem? > > Thanks in advance for your reply. > > Regards, > Daniel -- "We've had no evidence that Saddam Hussein was involved in Sept. 11." - George W. Bush 08/17/2003 Washington, DC |
OpenVPN
On Wednesday, 28 October 2009 07:39:18 -0700,
peasthope@shaw.ca wrote: > Daniel, Hi, Peter. > > Until this instance, starting a OpenVPN client in the office I could > > verify that the tunnel is established, but I can only reach the > > OpenVPN server. The rest of hosts of my LAN is unareachables. > > ... > > I have the impression that continues existing some routing problem > > somewhere. Some idea of what can be the problem? > > For a few years now I've run a VPN similar to what you describe. > http://carnot.yi.org/NetworksPage.html > > Observe entries such as "route 172.23.4.2" and > "# route shawmail.gv.shawcable.net" in > dalton: ... myvpn.conf. > > "route 172.23.4.2" allows a machine such as > Cantor at UBC to transmit to Curie at home. > > "route shawmail.gv.shawcable.net" allows Cantor > at UBC to send a message through the tunnel to > the SMTP server of my home ISP. The server will > not accept the message unless it comes from my > LAN. With this routing, the UBC and home LANs > are in effect one LAN. The domain name for SMTP > is associated with two IP addresses. For > routing to be reliable, both addresses must > specified explicitly. > > Shorewall is a superb example of open source > software. Documentation is excellent. Now I'm doing tests but this time with the OpenVPN server in the office and a client in my house. The OpenVPN server is behind firewall of the office. In these tests the tunnel is established between the client in my house and the OpenVPN server in the office. These are the tests that I got to do: 1.- Server with IP forwarding disable and no change in the present configuration of firewall: the client in my house is only able to reach to the OpenVPN server. 2.- Server with IP forwarding enable and no change in the present configuracion of firewall: same result that (1). 3.- Server with IP forwarding enable and I added the following routing rule in firewall: I can arrive additionally at firewall, but at no other host of the same network. # route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.0.0.38 This is the configuration of the client in my house: --------------------------------------------------------------------------- # cat /etc/openvpn/client1 client proto udp dev tun remote aaa.bbb.ccc.ddd 1194 # with aaa.bbb.ccc.ddd the public IP of OpenVPN server resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert client1.crt key client1.key comp-lzo verb 3 ns-cert-type server --------------------------------------------------------------------------- This is the configuration of the server in the office: --------------------------------------------------------------------------- # cat /etc/openvpn/server.conf port 1194 proto udp dev tun ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt crl-verify /etc/openvpn/easy-rsa/2.0/keys/crl.pem cert /etc/openvpn/easy-rsa/2.0/keys/server.crt key /etc/openvpn/easy-rsa/2.0/keys/server.key # This file should be kept secret dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun status /var/log/openvpn-status.log verb 3 push "route 10.0.0.0 255.255.255.0" push "dhcp-option DNS 10.0.0.11" push "dhcp-option DOMAIN local.net" --------------------------------------------------------------------------- Local network: 10.0.0.0/24 VPN network: 10.8.0.0/24 In the configuration of Shorewall I only added a rule of DNAT to the OpenVPN server: --------------------------------------------------------------------------- # DGB - 20091029 - OpenVPN DNAT inet saav:10.0.0.38 udp 1194 - aaa.bbb.ccc.ddd --------------------------------------------------------------------------- According to I see comparing what you have, is something different my configuration (road warrior?), but I have the impression that the problem that is existing is of routing of the side of the office. Thanks for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Squeeze - Linux user #188.598 |
OpenVPN
On Saturday 31 October 2009 11:27:46 am Daniel Bareiro wrote:
> On Wednesday, 28 October 2009 07:39:18 -0700, > > peasthope@shaw.ca wrote: > > Daniel, > > Now I'm doing tests but this time with the OpenVPN server in the office > and a client in my house. The OpenVPN server is behind firewall of the > office. > > In these tests the tunnel is established between the client in my house > and the OpenVPN server in the office. These are the tests that I got to > do: > > 1.- Server with IP forwarding disable and no change in the present > configuration of firewall: the client in my house is only able to reach > to the OpenVPN server. > > 2.- Server with IP forwarding enable and no change in the present > configuracion of firewall: same result that (1). > > 3.- Server with IP forwarding enable and I added the following routing > rule in firewall: I can arrive additionally at firewall, but at no other > host of the same network. > > # route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.0.0.38 > > This is the configuration of the client in my house: > > --------------------------------------------------------------------------- > Thanks for your reply. > > Regards, > Daniel man openvpn client-to-client? -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
| All times are GMT. The time now is 06:37 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.