<div dir="auto">I double checked firewalls. None running to affect traffic.<div dir="auto"><br></div><div dir="auto">I explicitly disabled rp_filter (defaults to loose) on both server and client. No improvement. Which side actually needs it?</div><div dir="auto"><br></div><div dir="auto">I enabled proxy_arp on server, and then on both server and client, again to no benefit. Does only the server need this?</div><div dir="auto"><br></div><div dir="auto">I enabled forwarding on the client (already done on the server), with no change in behavior.</div><div dir="auto"><br></div><div dir="auto">The client is on one VLAN, and the server is on another VLAN. The router in the middle is the internet gateway, and obfuscates the IPSec instance as eventually the tunnels will source from the external world.</div><div dir="auto"><br></div><div dir="auto">The client is configured to talk to the external interface of the gateway, which DNATs the traffic and forwards to the VPN device.</div><div dir="auto"><br></div><div dir="auto">The VPN device is listening for IPSec traffic on a virtual interface stacked on the loopback. The /24 network is advertised out via quagga/zebra/bgp. The tunnel establishes fine, and the client can send traffic. The traffic just never gets back to the client.</div><div dir="auto"><br></div><div dir="auto">I cannot tell if the IPSec server instance is passing the traffic and the client is not getting it, or if the server instance is not passing the traffic. How can I further dig into where the problem is?</div><div dir="auto"><br></div><div dir="auto">I have already tried reconfiguring the whole setup so the server is listening on a wired NIC and not the bgp advertised loopback interface. The same issue is seen, and the client does not properly see responses.</div><div dir="auto"><br></div><div dir="auto">Any help is appreciated.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Brendan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 1, 2021, 3:01 PM brendan kearney <<a href="mailto:bpk678@gmail.com" target="_blank" rel="noreferrer">bpk678@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">It seems this thread was marked as spam and caught in filters. I have some reading to do as 5 emails are "new to me". Will catch up and reply back. Thanks for the replies and help.<div dir="auto"><br></div><div dir="auto">Brendan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 1, 2021, 7:42 AM brendan kearney <<a href="mailto:bpk678@gmail.com" rel="noreferrer noreferrer" target="_blank">bpk678@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I commented out the compress directive on both server and client, and restarted services. The same behavior persists.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 1, 2021, 4:49 AM Paul Wouters <<a href="mailto:paul@nohats.ca" rel="noreferrer noreferrer noreferrer" target="_blank">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 1 Sep 2021, <a href="mailto:phil.nightowl@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">phil.nightowl@gmail.com</a> wrote:<br>
<br>
>> Don't use compress=yes<br>
><br>
> ... why (just being curious)? Is the compression not good enough to achieve<br>
> a real gain (even on low bandwidth lines)? Security issues? Misbehaved<br>
> implementation? Something else? And is it a bad idea only on the server<br>
> side, or did you just omit your comment in the client config?<br>
<br>
There is always a security risk on using compressing with encryption, as<br>
it can lead to oracle attacks. It also complicates the IPsec state, by<br>
adding a compress state on top of it, and then it compresses but if<br>
compress doesnt produce shorter result, uses the uncompressed version.<br>
So for example "ipsec trafficstatus" would have two entries, one for<br>
compressed and one for without.<br>
<br>
Hardly anyone uses compression ever.<br>
<br>
Also, we have a leak in that we don't delete the kernel compress state,<br>
but that is fixable :P<br>
<br>
Paul<br>
_______________________________________________<br>
Swan mailing list<br>
<a href="mailto:Swan@lists.libreswan.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">Swan@lists.libreswan.org</a><br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.libreswan.org/mailman/listinfo/swan</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>