From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephan Mending To: development@lists.ipfire.org Subject: Re: Incoming ESP Packets disappear Date: Wed, 13 May 2020 15:13:25 +0200 Message-ID: <20200513131325.GA68638@hellisempty.reich.home.arpa> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6581033873777372167==" List-Id: --===============6581033873777372167== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, May 04, 2020 at 04:03:13PM +0100, Michael Tremer wrote: > Hi Stephan, >=20 > What is the output of =E2=80=9Cipsec statusall=E2=80=9D on both systems? >=20 > Best, > -Michael >=20 > > On 30 Apr 2020, at 22:28, Stephan Mending wrote: > >=20 > > Hello, > >=20 > > I have a situation. ;) > >=20 > > It looks like the following: > >=20 > >=20 > > (SRV-01) ----------- (IPFIRE) -------orange------- (SRV-02) > >=20 > > public-IP 192.168.0.100 > >=20 > >=20 > > SRV-01 is hooked up to the ipfire via a roadwarrior IPsec connection. Est= ablishment of the tunnel works as one would expect it. > >=20 > > ping from SRV-02 to SRV-01 works fine and passes through the tunnel. So f= ar, so good. > >=20 > > ping from SRV-01 to SRV-02 does not. > >=20 > >=20 > > Iptables is blocking ? No, I did check that. Nothing. > >=20 > > IPS ? No, neither. > >=20 > >=20 > > So what's the matter ? When watching the interface using tcpdump I can se= e ESP packets and afterwards its unencrypted icmp echo request content (both = on ppp0). That is the end. > >=20 > > And the packet has never been seen any after. > >=20 > > Anyone an idea? > >=20 > >=20 > > (Yes the SRV-02 accepts incoming icmp type 8 and outgoing type 0) > >=20 > >=20 > > Best regards, > >=20 > > Stephan > >=20 > >=20 >=20 Hi Micheal,=20 thanks for your reply. I have done some changes to the setup. Just out of log= ical issues it had.=20 So the Situation changed but a Problem persists.=20 Maybe this "Problem" is intentionally that way. I'll explain.=20 One has to know: The machine (SRV-01) in the datacenter is running OpenBSD u= sing iked(8) to connect to the strongswan ipsec daemon.=20 That works for far pretty fine. DPD and rekeying is not a problem either.=20 But there seem to exist an issue on IPFire's site. Because from SRV-01 I cann= ot reach SRV-02 via icmp or tcp ... So to make sure that this isn't an issue with the packet filter or routing ta= ble on SRV-01 I checked via tcpdump that the packets I am sending to SRV-02 really reach the firewall. They do. Though as soon as I have pinged or reached out once to SRV-01 from SRV-02. It= works the other way around as well.=20 That's one thing. There are way to work around it. (-> They're ugly but they = exist) *** Next issue I was granted to be witness. After a few hours of the connection b= eing established (And being restablished due to rekeying etc) the strongswan just stops answering. Log on SRV-01 says:= Retransmit 1 IKE_SA_INIT ...=20 And it keeps trying to retransmit 'til eternity (and is unsuccesful at it). S= o again. I check if those retransmits reach the ipfire box. And yes they do. I can see the packets raining in on the ppp0 interface.=20 To resolve this issue I have to restart the connection from the ipfire webui = (by clicking the restart button).=20 Options for the connection on ipfire are: DPD -> clear and Connection type: W= ait for initiation.=20 I really hope you can help me here. I'd really appreciate it alot.=20 Thanks !=20 Best regards,=20 Stephan --===============6581033873777372167==--