[Swan] Road Warrior config

brendan kearney bpk678 at gmail.com
Tue Sep 7 18:08:55 UTC 2021


I double checked firewalls. None running to affect traffic.

I explicitly disabled rp_filter (defaults to loose) on both server and
client. No improvement.  Which side actually needs it?

I enabled proxy_arp on server, and then on both server and client, again to
no benefit. Does only the server need this?

I enabled forwarding on the client (already done on the server), with no
change in behavior.

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.

The client is configured to talk to the external interface of the gateway,
which DNATs the traffic and forwards to the VPN device.

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.

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?

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.

Any help is appreciated.

Thanks,
Brendan

On Wed, Sep 1, 2021, 3:01 PM brendan kearney <bpk678 at gmail.com> wrote:

> 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.
>
> Brendan
>
> On Wed, Sep 1, 2021, 7:42 AM brendan kearney <bpk678 at gmail.com> wrote:
>
>> I commented out the compress directive on both server and client, and
>> restarted services.  The same behavior persists.
>>
>> On Wed, Sep 1, 2021, 4:49 AM Paul Wouters <paul at nohats.ca> wrote:
>>
>>> On Wed, 1 Sep 2021, phil.nightowl at gmail.com wrote:
>>>
>>> >> Don't use compress=yes
>>> >
>>> > ... why (just being curious)? Is the compression not good enough to
>>> achieve
>>> > a real gain (even on low bandwidth lines)? Security issues? Misbehaved
>>> > implementation? Something else? And is it a bad idea only on the server
>>> > side, or did you just omit your comment in the client config?
>>>
>>> There is always a security risk on using compressing with encryption, as
>>> it can lead to oracle attacks. It also complicates the IPsec state, by
>>> adding a compress state on top of it, and then it compresses but if
>>> compress doesnt produce shorter result, uses the uncompressed version.
>>> So for example "ipsec trafficstatus" would have two entries, one for
>>> compressed and one for without.
>>>
>>> Hardly anyone uses compression ever.
>>>
>>> Also, we have a leak in that we don't delete the kernel compress state,
>>> but that is fixable :P
>>>
>>> Paul
>>> _______________________________________________
>>> Swan mailing list
>>> Swan at lists.libreswan.org
>>> https://lists.libreswan.org/mailman/listinfo/swan
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20210907/535a9a74/attachment.html>


More information about the Swan mailing list