[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Delivery Status Notification (Delay)



This is an automatically generated Delivery Status Notification.

THIS IS A WARNING MESSAGE ONLY.

YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Delivery to the following recipients has been delayed.

       funfun2000@xxxxxxxxxxx



Reporting-MTA: dns;mc8-s7.hotmail.com
Received-From-MTA: dns;mc8-f34.hotmail.com
Arrival-Date: Tue, 21 Oct 2003 20:46:22 -0700

Original-Recipient: 
Final-Recipient: rfc822;funfun2000@hotmail.com
Action: delayed
Status: 4.4.7
Will-Retry-Until: Wed, 22 Oct 2003 20:46:26 -0700
--- Begin Message ---
  • Subject: Re: [Openvpn-users] OpenVPN through firewalls.
  • From: "James Yonan" <jim@xxxxxxxxx>
  • Date: Tue, 21 Oct 2003 22:11:13 -0000
Ged Haywood <ged@xxxxxxxxxxxxxxxxxxxxxxx> said:

> Hi James,
> 
> Overnight when Wanadoo changed my IP address, my OpenVPN link stopped
> and didn't restart.  I can verify that it was precisely at this time
> (01:48 BST) that the VPN failed.  This is still using -beta9, but now
> that both -9 and -12 have done (almost) the same thing I'll probably
> install -12 as you suggested.  I say 'almost' since it seemed to be
> much easier to restart -9 (a couple of minutes) when it failed than
> -12 was (over an hour).  This could of course be chance, or it could
> be because I had a better idea of where to look this time.
>
> I couldn't ping either end of the 10.3.0.x link.  To restart it I
> first shut down and restarted the OpenVPN server.  I verified after
> shutting down the OpenVPN instance that the tun device was down too.
> OpenVPN appeared to restart OK, and the tun device was present, but
> the link was still dead.
> 
> Next I shut down both ends, server and client, and restarted both
> (server instance first).  This time the link came back up right away.

One common problem with OpenVPN + DHCP is that one peer gets a DHCP reset,
starts sending packets to its remote host on a new address, and the stateful
firewall of the remote host rejects the packets because they appear to be
coming from an unknown address.

There are two solutions here:

(1) Create an explicit firewall rule for each host which spans the complete
subnet from which the remote hosts's DHCP addresses might be allocated from.

(2) Use a dynamic DNS provider (such as dyndns.org) so that each host can
"follow" the other.

I have personally used (2) with success and it is described at length in the FAQ.

James


____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users


--- End Message ---