Topics

Hello!

I have a scenario I'm working with where it is not feasible to do a PKI infrastructure for the purpose of VPN client authentication. Instead, we want to use Username/Password authentication through RADIUS.

In this scenario, I am not expecting a certificate authority to be neccessary to configure, since the authentication happens through:

1. A pre-shared key for TLS auth (to protect the initial exchange and provide some protection from casual password bruteforce attacks, because you cannot even try a password unless you have this PSK)
2. Username and passsword

In this scenario, I don't see the purpose of a certificate authority, yet it is forced for me to configure one for this scenario. Am I misunderstanding something about how this is supposed to work? Also, a "server certificate" is required, I'm not sure where this is used?

More generally, my concern is, I want to be aware of any "time bombs" in the system. For example, what if this (useless?) CA certificate expires.

Hello!

I have the following scenario. A firewall with two LAN interfaces, one for printers, and one for the PC LAN.

Printers will be receiving new IP addresses, but some clients are still configured with old IP addresses. For this reason, we want to set up NAT so that if a device on the LAN tries to reach one of the old printer IP's, NAT is used to translate the destination address to the new printer ip.

As such the following 1:1 NAT rule has been created:

Disabled: OFF
Interface: LAN
Type: NAT
External network: <old printer IP>/32
Source/Invert: OFF
Source: LAN net
Destination/Invert: OFF
Destination: Single host or network (<new printer IP>/32)
NAT reflection: <use system default>

This results in the following entry in /tmp/rules.debug:

nat on lagg0 from (lagg0:network) to <new printer IP> -> <old printer IP>/32

But this to me looks like it's backwards somehow... I would expect instead it being old->new? But it doesn't work even if I external network and destination... whatever I do I just get the untranslated packet egressing on WAN (default route) instead...

Am I missing something?

Hi.

I'm trying to set up a pair of OPNsense boxes in a CARP HA setup, with IPv6, and I'm stuck on how to get router advertisements to work correctly.

Router advertisements are set up as follows:

Router Advertisements: Stateless
Router Priority: Normal (Low on the secondary unit)
RA Interface: LAN_VIP11 (corresponds to the CARP address)
Advertize default gateway: Yes
DNS Servers: Set to the CARP address
Minimum interval: 200
Maximum interval: 600

Rest is left blank.

At this point I'm expecting router advertisements to advertise the CARP address as a default gateway to IPv6 clients on the lan, but instead, the link local addresses as well as the individual IP addresses of each router are all advertised as defautl gateways, causing CARP not to operate correctly. Sometimes it doesn't work right and traffic goes out of the secondary firewall, which means return traffic is never passed because triangular routing.

Am I missing some secret sauce to get CARP addresses to work properly with router advertisements?

I have some feedback regarding the default behavior for inbound firewall rules on the WAN interface of OPNsense 20.1, and I believe this problem is also present in earlier versions.

Consider a network that looks like this:

Code Select Expand


   __   _
_(  )_( )_
(_   _    _) Internet
  (_) (__)
    |
.---'--------.    .-----------.
| WAN Router |    | Computer  |
| 192.0.2.1  |    | 192.0.2.2 |
'---.--------'    '-----.-----'
    |                   |
    |                   |
.---'-------------------'---.
| 192.0.2.0/24 WAN Network  |
'------.--------------------'
       |
       | WAN (igb1)
.------'------------.
| OPNsense Firewall |
| 192.0.2.3         |
| 192.168.0.1       |
'------.------------'
       | LAN (igb0)
       |
.------'---------------------.
| 192.168.0.0/24 LAN Network |
'----------------------------'


Consider that there is a firewall rule the OPNsense box, on the WAN interface which permits traffic from 192.0.2.2 to 192.0.2.3 TCP PORT 443. All other options default.

By default, OPNsense seems to create this firewall rule with a "reply-to" clause, which means that any reponse to the SYN sent by the computer is not sent back to the computer, but instead back to the default gateway on the WAN network.

This will work most of the time (except wasting sending traffic to and from the gateway), but if the gateway is itself another stateful firewall (like another OPNsense box), this causes the connection to never be established.

The solution is to check "disable reply-to" on the inbound firewall rule on the WAN.

Not sure when this became the default, it seems to have been the case since at least 2018. https://forum.opnsense.org/index.php?topic=8841.0 Although I'm not finding this global checkbox that @franco was referring to.

Now, I understand the reason for this default "reply-to" behavior, which is to ensure that in a multi-WAN scenario, you don't get triangular routing, but instead the way it's implemented, you end up with triangular traffic flow in the basic case.

A sane default would be to not enable reply-to unless the user selects a gateway on the rule. (In fact, when you just select "default" as the gateway, the help says the system routing table is used, which is NOT true.)

Another possible fix for a solution that "just works" that both works for preventing triangular routing in multi-WAN scenario and doesn't break local WAN commmunication is to install two pf rules in the back end, which disables reply-to for traffic coming from a host directly connected on the WAN network. Something like:

Code Select Expand


pass in quick on igb1                             inet proto tcp from {{igb1:network}} to {{self}} port {443} keep state
pass in quick on igb1 reply-to { igb1 192.0.2.1 } inet proto tcp from {any}            to {{self}} port {443} keep state


Of course all of this can be configured by an admin directly in the GUI, if you don't mind some doubled firewall rules.

To summarize, I don't expect Policy Based Routing to be implemented by default unless i specifically turn it off in advanced settings.

Hello!

I'm trying to get the os-acme-client plugin to work in order to enable me to generate an SSL certificate. I plan on using this SSL certificate for the WebConfigurator and the postfix plugin. Right now I'm stuck with it not working. It appears to fail on the HTTP-01 validation part. Here's the output of acme.sh.log:

Code Select Expand

[Fri Dec  6 11:11:49 CET 2019] Using stage ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory
[Fri Dec  6 11:11:49 CET 2019] ACME_DIRECTORY='https://acme-staging-v02.api.letsencrypt.org/directory'
[Fri Dec  6 11:11:49 CET 2019] DOMAIN_PATH='/var/etc/acme-client/home/xxxx.xxxx.xxxx.xxxx'
[Fri Dec  6 11:11:50 CET 2019] Using ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory
[Fri Dec  6 11:11:50 CET 2019] _init api for server: https://acme-staging-v02.api.letsencrypt.org/directory
[Fri Dec  6 11:11:50 CET 2019] GET
[Fri Dec  6 11:11:50 CET 2019] url='https://acme-staging-v02.api.letsencrypt.org/directory'
[Fri Dec  6 11:11:50 CET 2019] timeout=
[Fri Dec  6 11:11:50 CET 2019] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g '
[Fri Dec  6 11:11:50 CET 2019] ret='0'
[Fri Dec  6 11:11:50 CET 2019] ACME_KEY_CHANGE='https://acme-staging-v02.api.letsencrypt.org/acme/key-change'
[Fri Dec  6 11:11:50 CET 2019] ACME_NEW_AUTHZ
[Fri Dec  6 11:11:50 CET 2019] ACME_NEW_ORDER='https://acme-staging-v02.api.letsencrypt.org/acme/new-order'
[Fri Dec  6 11:11:50 CET 2019] ACME_NEW_ACCOUNT='https://acme-staging-v02.api.letsencrypt.org/acme/new-acct'
[Fri Dec  6 11:11:50 CET 2019] ACME_REVOKE_CERT='https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert'
[Fri Dec  6 11:11:50 CET 2019] ACME_AGREEMENT='https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf'
[Fri Dec  6 11:11:50 CET 2019] ACME_NEW_NONCE='https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce'
[Fri Dec  6 11:11:50 CET 2019] ACME_VERSION='2'
[Fri Dec  6 11:11:50 CET 2019] Le_NextRenewTime
[Fri Dec  6 11:11:51 CET 2019] _on_before_issue
[Fri Dec  6 11:11:51 CET 2019] _chk_main_domain='xxxx.xxxx.xxxx.xxxx'
[Fri Dec  6 11:11:51 CET 2019] _chk_alt_domains
[Fri Dec  6 11:11:51 CET 2019] Le_LocalAddress
[Fri Dec  6 11:11:51 CET 2019] d='xxxx.xxxx.xxxx.xxxx'
[Fri Dec  6 11:11:51 CET 2019] Check for domain='xxxx.xxxx.xxxx.xxxx'
[Fri Dec  6 11:11:51 CET 2019] _currentRoot='/var/etc/acme-client/challenges'
[Fri Dec  6 11:11:51 CET 2019] d
[Fri Dec  6 11:11:51 CET 2019] _saved_account_key_hash is not changed, skip register account.
[Fri Dec  6 11:11:51 CET 2019] Read key length:4096
[Fri Dec  6 11:11:51 CET 2019] _createcsr
[Fri Dec  6 11:11:51 CET 2019] Single domain='xxxx.xxxx.xxxx.xxxx'
[Fri Dec  6 11:11:51 CET 2019] Getting domain auth token for each domain
[Fri Dec  6 11:11:51 CET 2019] d
[Fri Dec  6 11:11:51 CET 2019] url='https://acme-staging-v02.api.letsencrypt.org/acme/new-order'
[Fri Dec  6 11:11:51 CET 2019] payload='{"identifiers": [{"type":"dns","value":"xxxx.xxxx.xxxx.xxxx"}]}'
[Fri Dec  6 11:11:51 CET 2019] RSA key
[Fri Dec  6 11:11:55 CET 2019] HEAD
[Fri Dec  6 11:11:55 CET 2019] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce'
[Fri Dec  6 11:11:55 CET 2019] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g  -I  '
[Fri Dec  6 11:11:56 CET 2019] _ret='0'
[Fri Dec  6 11:11:56 CET 2019] POST
[Fri Dec  6 11:11:56 CET 2019] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/new-order'
[Fri Dec  6 11:11:56 CET 2019] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g '
[Fri Dec  6 11:11:56 CET 2019] _ret='0'
[Fri Dec  6 11:11:56 CET 2019] code='201'
[Fri Dec  6 11:11:56 CET 2019] Le_LinkOrder='https://acme-staging-v02.api.letsencrypt.org/acme/order/11730069/64725734'
[Fri Dec  6 11:11:56 CET 2019] Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/11730069/64725734'
[Fri Dec  6 11:11:56 CET 2019] url='https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/25578479'
[Fri Dec  6 11:11:56 CET 2019] payload
[Fri Dec  6 11:11:57 CET 2019] POST
[Fri Dec  6 11:11:57 CET 2019] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/25578479'
[Fri Dec  6 11:11:57 CET 2019] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g '
[Fri Dec  6 11:11:57 CET 2019] _ret='0'
[Fri Dec  6 11:11:57 CET 2019] code='200'
[Fri Dec  6 11:11:57 CET 2019] d='xxxx.xxxx.xxxx.xxxx'
[Fri Dec  6 11:11:57 CET 2019] Getting webroot for domain='xxxx.xxxx.xxxx.xxxx'
[Fri Dec  6 11:11:57 CET 2019] _w='/var/etc/acme-client/challenges'
[Fri Dec  6 11:11:57 CET 2019] _currentRoot='/var/etc/acme-client/challenges'
[Fri Dec  6 11:11:57 CET 2019] entry='"type":"http-01","status":"pending","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA","token":"ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE"'
[Fri Dec  6 11:11:57 CET 2019] token='ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE'
[Fri Dec  6 11:11:57 CET 2019] uri='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA'
[Fri Dec  6 11:11:57 CET 2019] keyauthorization='ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE.8P8EUCx8vW70bIDfd3neQhhfOrfPj2UOg3MZ7k-rUf8'
[Fri Dec  6 11:11:57 CET 2019] dvlist='xxxx.xxxx.xxxx.xxxx#ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE.8P8EUCx8vW70bIDfd3neQhhfOrfPj2UOg3MZ7k-rUf8#https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA#http-01#/var/etc/acme-client/challenges'
[Fri Dec  6 11:11:57 CET 2019] d
[Fri Dec  6 11:11:57 CET 2019] vlist='xxxx.xxxx.xxxx.xxxx#ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE.8P8EUCx8vW70bIDfd3neQhhfOrfPj2UOg3MZ7k-rUf8#https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA#http-01#/var/etc/acme-client/challenges,'
[Fri Dec  6 11:11:57 CET 2019] d='xxxx.xxxx.xxxx.xxxx'
[Fri Dec  6 11:11:57 CET 2019] ok, let's start to verify
[Fri Dec  6 11:11:58 CET 2019] Verifying: xxxx.xxxx.xxxx.xxxx
[Fri Dec  6 11:11:58 CET 2019] d='xxxx.xxxx.xxxx.xxxx'
[Fri Dec  6 11:11:58 CET 2019] keyauthorization='ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE.8P8EUCx8vW70bIDfd3neQhhfOrfPj2UOg3MZ7k-rUf8'
[Fri Dec  6 11:11:58 CET 2019] uri='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA'
[Fri Dec  6 11:11:58 CET 2019] _currentRoot='/var/etc/acme-client/challenges'
[Fri Dec  6 11:11:58 CET 2019] wellknown_path='/var/etc/acme-client/challenges/.well-known/acme-challenge'
[Fri Dec  6 11:11:58 CET 2019] writing token:ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE to /var/etc/acme-client/challenges/.well-known/acme-challenge/ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE
[Fri Dec  6 11:11:58 CET 2019] Changing owner/group of .well-known to root:wheel
[Fri Dec  6 11:11:58 CET 2019] url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA'
[Fri Dec  6 11:11:58 CET 2019] payload='{}'
[Fri Dec  6 11:11:58 CET 2019] POST
[Fri Dec  6 11:11:58 CET 2019] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA'
[Fri Dec  6 11:11:58 CET 2019] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g '
[Fri Dec  6 11:11:58 CET 2019] _ret='0'
[Fri Dec  6 11:11:58 CET 2019] code='200'
[Fri Dec  6 11:11:58 CET 2019] trigger validation code: 200
[Fri Dec  6 11:11:58 CET 2019] sleep 2 secs to verify
[Fri Dec  6 11:12:00 CET 2019] checking
[Fri Dec  6 11:12:00 CET 2019] url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA'
[Fri Dec  6 11:12:00 CET 2019] payload
[Fri Dec  6 11:12:01 CET 2019] POST
[Fri Dec  6 11:12:01 CET 2019] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA'
[Fri Dec  6 11:12:01 CET 2019] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g '
[Fri Dec  6 11:12:01 CET 2019] _ret='0'
[Fri Dec  6 11:12:01 CET 2019] code='200'
[Fri Dec  6 11:12:01 CET 2019] xxxx.xxxx.xxxx.xxxx:Verify error:Invalid response from https://xxxx.xxxx.xxxx.xxxx/?url=/.well-known/acme-challenge/ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE [xxxx:xxxx:xxxx::xxxx]:
[Fri Dec  6 11:12:01 CET 2019] pid
[Fri Dec  6 11:12:01 CET 2019] No need to restore nginx, skip.
[Fri Dec  6 11:12:01 CET 2019] _clearupdns
[Fri Dec  6 11:12:01 CET 2019] dns_entries
[Fri Dec  6 11:12:01 CET 2019] skip dns.
[Fri Dec  6 11:12:01 CET 2019] _on_issue_err
[Fri Dec  6 11:12:01 CET 2019] Please check log file for more details: /var/log/acme.sh.log
[Fri Dec  6 11:12:01 CET 2019] url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA'
[Fri Dec  6 11:12:01 CET 2019] payload='{}'
[Fri Dec  6 11:12:02 CET 2019] POST
[Fri Dec  6 11:12:02 CET 2019] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/25578479/T3trFA'
[Fri Dec  6 11:12:02 CET 2019] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header  -g '
[Fri Dec  6 11:12:02 CET 2019] _ret='0'
[Fri Dec  6 11:12:02 CET 2019] code='400'


I would like to highlight this particular log line:

Code Select Expand


[Fri Dec  6 11:12:01 CET 2019] xxxx.xxxx.xxxx.xxxx:Verify error:Invalid response from https://xxxx.xxxx.xxxx.xxxx/?url=/.well-known/acme-challenge/ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE [xxxx:xxxx:xxxx::xxxx]:


To me this appears to show that Let's Encrypt's servers are ending up at https://xxxx.xxxx.xxxx.xxxx/?url=/.well-known/acme-challenge/ZjTUcsz8vjlno3PCnuiHfAyERnmNnZJUFV9bpmaKtmE but getting an invalid response. The fact that it's trying to access the acme-challenge over https, and the bogus ?url= part, indicates some kind of redirect that's happening in the OPNsense webconfigurator. This further indicates that a hole is being poked in the firewall correctly.

See attachment to see my validation configuration. I've also tried auto discover IP's but for now I've just hard-coded the IPv4 and IPv6 addresses of the firewall.