Messages

How is

Code Select Expand

local host is behind NAT, sending keep alives
determined? Is it due to what the far-end says ["you are behind NAT"], or is it some other heuristic? I am seeing it in a scenario where there is definitely no NAT at my end ["local host"] and almost certainly not at the far end.

Firewall with 2x WAN interfaces with public IPs. 1 LAN with private IP. Only routes to far end of tunnel are using WAN interfaces.
I see that "local host is behind NAT, sending keep alives" even though there is no NAT involved. How is the firewall determining that NAT is in use?

Are you sure this does not create any race conditions between the GUI config and the overwritten config?

I am not really sure about anything because I don't have Ph1 + Ph2 up and traffic passing yet and I have guessed how to configure this because I find the documentation to be unclear. However, if the "include" feature in Strongswan turns out to have some race condition which results in an indeterminate configuration, then that would be a pretty serious caveat [which should be documented loud and clear], and probably renders the include mechanism unusable in production environments.

Is it always the same proposals after every reload/restart of the service?

I can test that easily enough with, say, 10 restarts of the service.

[always remembering in future]

Isabella, did you manage to have the tunnel fully working?

I wish I could tell you - the other end just keeps sending back NO_PROP and the administrator doesn't seem to know how to look at his logs. But I am confident that my end is using what I think I have configured, as my logs agree with the config I have created. But you just need to bear in mind that I don't 100% know my assertion of how to configure this is true, because I don't have a ph2 up yet :)

Also, in your custom conf file - did you use the connection id the same as in swanctl.conf, or you created full new settings (including p2 children section etc.)? Thanks!

No, not full new settings. Just overriding some elements of what was configured in UI, and then always remembering in future that what the UI says about the configuration may not be true.
The UUIDs need to match at each level.

Code Select Expand


connections {
    <the connection UUID from swanctl.conf> {
        proposals = aes256-sha1-modp1024
        children {
            <the child UUID from swanctl.conf> {
                esp_proposals = aes256-sha1
       
        }
}
}
}



As I happens, I managed to work this out.
Given a generated configuration:

Code Select Expand

# cat /usr/local/etc/swanctl/swanctl.conf
# This file is automatically generated. Do not edit
connections {
    00000000-0000-0000-0000-000000000000 {
        proposals = aes256-sha1-modp2048
        unique = no
        aggressive = no
<snip>



We create an override .conf file containing:

Code Select Expand


connections {
    00000000-0000-0000-0000-000000000000 {
        proposals = aes256-sha1-modp1024
        }
}


restart the service and the log confirms that modp1024 was used, not modp2048. There is NO indication in the config GUI that this has happened.

Unfortunately vpnet.html is not clear on what is required here.
Am I supposed to do the entire VPN tunnel configuration as a new file in /usr/local/etc/strongswan.opnsense.d/? Or am I able to override one or more parameters by dropping a file in there?
The documentation needs some examples of what custom config looks like.

Does this note in the documentation which says "...will not be mainted by the user interface,..." mean that it won't be possible to choose a custom proposal from the UI? If that is true then how would they be applied to an IPsec policy?

Two routers set up in HA, two WANS /29 and /30. Standby router cannot use gateway on /30 as there aren't enough IPs, so Monit constantly complains about it being down.
Can I get Monit to ignore the /30 WAN? So long as at least one WAN works, that's "good enough".

OK, I was going to show the logs of it working but it looks no different, so there's no point. Drill in to it, it's the same RID. Definitely the correct rule on the correct interface.

Logs of it not working [reply-to: default]. The source IPs are all in the "Management" alias.

I guess it's this, but it's already not-disabled.

Deleted the floating rule. Rebooted. No different, management access does not work unless an explicit reply-to gateway is specified.

What is the "unless globally disabled" hinting at?

Well that's annoying because a multi-WAN is the only use I've ever had for a floating rule  ::)  ;D

Yes, I started with a floating rule but it did not work, so I created individual rules.
However I just realised I left the floating rule in place, so I will remove this and re-test, in case it somehow takes precedence and breaks it.

No, it's set to default which is "all".