public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
* Re: Incoming ESP Packets disappear
       [not found] <de3b625a-dae3-b5bb-96d3-cf084f911b85@md5collisions.eu>
@ 2020-05-04 15:03 ` Michael Tremer
  2020-05-13 13:13   ` Stephan Mending
  0 siblings, 1 reply; 2+ messages in thread
From: Michael Tremer @ 2020-05-04 15:03 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

Hi Stephan,

What is the output of “ipsec statusall” on both systems?

Best,
-Michael

> On 30 Apr 2020, at 22:28, Stephan Mending <list(a)md5collisions.eu> wrote:
> 
> Hello,
> 
> I have a situation. ;)
> 
> It looks like the following:
> 
> 
> (SRV-01) ----------- (IPFIRE) -------orange------- (SRV-02)
> 
> public-IP     192.168.0.100
> 
> 
> SRV-01 is hooked up to the ipfire via a roadwarrior IPsec connection. Establishment of the tunnel works as one would expect it.
> 
> ping from SRV-02 to SRV-01 works fine and passes through the tunnel. So far,  so good.
> 
> ping from SRV-01 to SRV-02 does not.
> 
> 
> Iptables is blocking ? No, I did check that. Nothing.
> 
> IPS ? No, neither.
> 
> 
> So what's the matter ? When watching the interface using tcpdump I can see ESP packets and afterwards its unencrypted icmp echo request content (both on ppp0). That is the end.
> 
> And  the packet has never been seen any after.
> 
> Anyone an idea?
> 
> 
> (Yes the SRV-02 accepts incoming icmp type 8  and outgoing type 0)
> 
> 
> Best regards,
> 
> Stephan
> 
> 


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Incoming ESP Packets disappear
  2020-05-04 15:03 ` Incoming ESP Packets disappear Michael Tremer
@ 2020-05-13 13:13   ` Stephan Mending
  0 siblings, 0 replies; 2+ messages in thread
From: Stephan Mending @ 2020-05-13 13:13 UTC (permalink / raw)
  To: development

[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]

On Mon, May 04, 2020 at 04:03:13PM +0100, Michael Tremer wrote:
> Hi Stephan,
> 
> What is the output of “ipsec statusall” on both systems?
> 
> Best,
> -Michael
> 
> > On 30 Apr 2020, at 22:28, Stephan Mending <list(a)md5collisions.eu> wrote:
> > 
> > Hello,
> > 
> > I have a situation. ;)
> > 
> > It looks like the following:
> > 
> > 
> > (SRV-01) ----------- (IPFIRE) -------orange------- (SRV-02)
> > 
> > public-IP     192.168.0.100
> > 
> > 
> > SRV-01 is hooked up to the ipfire via a roadwarrior IPsec connection. Establishment of the tunnel works as one would expect it.
> > 
> > ping from SRV-02 to SRV-01 works fine and passes through the tunnel. So far,  so good.
> > 
> > ping from SRV-01 to SRV-02 does not.
> > 
> > 
> > Iptables is blocking ? No, I did check that. Nothing.
> > 
> > IPS ? No, neither.
> > 
> > 
> > So what's the matter ? When watching the interface using tcpdump I can see ESP packets and afterwards its unencrypted icmp echo request content (both on ppp0). That is the end.
> > 
> > And  the packet has never been seen any after.
> > 
> > Anyone an idea?
> > 
> > 
> > (Yes the SRV-02 accepts incoming icmp type 8  and outgoing type 0)
> > 
> > 
> > Best regards,
> > 
> > Stephan
> > 
> > 
> 

Hi Micheal, 
thanks for your reply. I have done some changes to the setup. Just out of logical issues it had. 
So the Situation changed but a Problem persists. 
Maybe this "Problem" is intentionally that way. I'll explain. 

One has to know: The machine (SRV-01)  in the datacenter is running OpenBSD using iked(8) to connect to the strongswan
ipsec daemon. 

That works for far pretty fine. DPD and rekeying is not a problem either. 

But there seem to exist an issue on IPFire's site. Because from SRV-01 I cannot reach SRV-02 via icmp or tcp ...

So to make sure that this isn't an issue with the packet filter or routing table 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. 


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 being established (And being restablished
due to rekeying etc) the strongswan just stops answering. Log on SRV-01 says: Retransmit 1 IKE_SA_INIT ... 
And it keeps trying to retransmit 'til eternity (and is unsuccesful at it). So 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. 

To resolve this issue I have to restart the connection from the ipfire webui (by clicking the restart button). 
Options for the connection on ipfire are: DPD -> clear and Connection type: Wait for initiation. 


I really hope you can help me here. I'd really appreciate it alot. 

Thanks ! 

Best regards, 
Stephan



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-05-13 13:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <de3b625a-dae3-b5bb-96d3-cf084f911b85@md5collisions.eu>
2020-05-04 15:03 ` Incoming ESP Packets disappear Michael Tremer
2020-05-13 13:13   ` Stephan Mending

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox