Messages

Actually I tried to split port 443 in HAProxy. I couldn't find a working solution for my setup. While struggling around Cedrik gave me the hint to try Caddy. The idea behind HAProxy was to restrict access to the LAN and to present all certs to any clients or applications in the LAN. Connections from outside are only allowed through VPN. In this setup there's only a minimum of ports at the WAN interface open.

The main reason for port-sharing is that more and more wifi's in hotels or airports have only two ports open. As long as there's no deep packet inspection, one could use port 443 for openvpn. In other enviroments wireguard maybe a good choice.

Here are the steps sharing the port 443 between openvpn and a web application running on https, which are working for me. As pre-requisites there are (up-to-date)

OPNsense 24.7.9_1-amd64
FreeBSD 14.1-RELEASE-p6
OpenSSL 3.0.15

- all DNS records setup at the ISP/DNS registrar
- all (let's encrypt) certificates are stored at the correct local places and up-to-date
- there's a user created for openvpn
- local certificates have been created for the vpn-server and the vpn-client (user)
- there's a VPN instance up and running bound to 127.0.0.1 on port 1194

a) in Caddy - general settings - enable caddy and layer4 proxy. Advanced, Log, DNS, etc. are left on default.
b) in reverse proxy - http access - create your acl. I allow access only to LAN and VPN. HTTP response code for me is 403, the message is "HTTP 403 - Forbidden"
c) in reverse proxy - Domains - create your web-application on port 443 (https). Don't forget the corresponding certificate and the access list to this application.
d) in reverse proxy - http handlers - create the web-application which belongs to step c). Handler is "handle", leave path to "any", directive is "reverse_proxy", leave http version on default, protocol is "https", define your upstream domain/IP on the upstream port 443. Leave upstream path empty. Change the TLS server name that matches the SAN "Subject Alternative Name" of the offered upstream certificate.
e) in layer4 proxy - leave/change routing type "listener_wrappers", protocol is TCP, local port leave empty, matchers is "openvpn", mode and key is "any", upstream domain is "127.0.0.1", upstream port is 1194. Leave the rest empty/on default.

Connect your roadwarrior through port 443 to the openvpn instance. I used for client export "file only".

That's it. Working at least for me. If there are questions with this setup, I'll try to help. I had to start over for a second try. The first approach didn't work as expected. While re-installing (I removed every leftover from caddy via cli) it worked in the way I described. This time I was better prepared and didn't change or alter any setting while configuring caddy. Be sure to have all pre-requisites working as they should. Then start configuring caddy.

I can't push the DNS through the linux client (not working with WIN-clients), access to the LAN apps works only with IP's. Or connecting via vnc to a machine in the LAN. I can live with that. Or maybe someone is able to rule this out.

regards,
stefan

P.S. thank's to cedrik - all credits to him

Getting closer while following this: https://forum.opnsense.org/index.php?topic=18538.0

For the https_passthrough I set the Type to SSL / HTTPS (TCP mode). The tcp-request inspect delay is set to 10s. (maybe to high?)

For testing I disabled all servers, backends and frontends from the tutorial. For the moment HAProxy passes through to Openvpn on port 443. I'm able to connect my roadwarrior through HAProxy to openvpn on port 443.

HAProxy config looks like this:

global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbthread                    2
    hard-stop-after             60s
    no strict-limits
    maxconn                     50
    tune.ssl.ocsp-update.mindelay 300
    tune.ssl.ocsp-update.maxdelay 3600
    httpclient.resolvers.prefer   ipv4
    tune.ssl.default-dh-param   4096
    spread-checks               2
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 info
    lua-prepend-path            /tmp/haproxy/lua/?.lua

defaults
    log     global
    option redispatch -1
    maxconn 10
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc
    default-server maxconn 10

# autogenerated entries for ACLs


# autogenerated entries for config in backends/frontends

# autogenerated entries for stats




# Frontend (DISABLED): 0_SNI_frontend (Listening on 0.0.0.0:80, 0.0.0.0:443)

# Frontend (DISABLED): 1_HTTP_frontend (Listening on 127.0.0.1:80)

# Frontend (DISABLED): 2_HTTPS_frontend (Listening on 127.0.0.1:443)

# Frontend: https_passthrough ()
frontend https_passthrough
    bind 0.0.0.0:443 name 0.0.0.0:443
    mode tcp

    # logging options
    # ACL: traffic_ssl
    acl acl_6741bff6e05423.95774512 req_ssl_hello_type 1
    # ACL: sni_mydomain_condition
    acl acl_6740b3e1c59208.20735171 req.ssl_sni -i abc.mydomain.de

    # ACTION: request_inspect_delay
    # NOTE: actions with no ACLs/conditions will always match
    tcp-request inspect-delay 10s
    # ACTION: request_content_accept_ssl
    tcp-request content accept if acl_6741bff6e05423.95774512
    # ACTION: myservice_sni
    use_backend VPN_backend if acl_6740b3e1c59208.20735171

# Backend (DISABLED): SERVER_backend ()

# Backend (DISABLED): SSL_backend ()

# Backend (DISABLED): MTA_STS_backend ()

# Backend: VPN_backend ()
backend VPN_backend
    # health checking is DISABLED
    mode tcp
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    server VPN_server my_ip

Now the next tricky part: how to merge/integrate this config into the 0_SNI_frontend of the tutorial?

Here's another solution:

https://www.reddit.com/r/selfhosted/comments/i0iq4g/guide_haproxy_with_openvpn/

"global
   log /dev/log   local0
   log /dev/log   local1 notice
   tune.ssl.default-dh-param 2048
   chroot /var/lib/haproxy
   stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
   stats timeout 30s
   user haproxy
   group haproxy
   daemon
   ca-base /etc/ssl/certs
   crt-base /etc/ssl/private
   ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
   ssl-default-bind-options no-sslv3

defaults
   log      global
   mode   http
   option   httplog
   option   dontlognull
   timeout connect 5s
   timeout client   50s
   timeout server   50s

frontend http
   bind :80
   mode http
   option http-keep-alive
   option forwardfor
   timeout client 30s
   # Redirect everything to https
   redirect scheme https code 301 if !{ ssl_fc }

frontend TLS_passthrough
   bind :443
   mode tcp
   option tcplog
   tcp-request inspect-delay 5s
   tcp-request content accept if { req_ssl_hello_type 1 } or !{ req_ssl_hello_type 1 }
   # Change this to your domain
   use_backend tcp_to_https if { req_ssl_sni -m end .yourdomain.tld }
   default_backend openvpn
      acl http req.ssl_ver gt 0

backend tcp_to_https
   mode tcp
   timeout connect 30s
   timeout server 30s
   server https 127.0.0.1:8443

frontend https
   bind :8443 ssl crt-list /etc/ssl/haproxy.certlist
   mode http
   option http-keep-alive
   option forwardfor
   timeout client 30s

   acl acl_guacamole hdr_beg(host) -i guacamole
   acl acl_plex hdr_beg(host) -i plex

   use_backend guacamole if acl_guacamole
   use_backend plex if acl_plex

backend openvpn
   mode tcp
   timeout connect 30s
   timeout server 30s
   retries 3
   server openvpn 192.168.100.218:443

backend plex
   mode http
   balance source
   stick-table type ip size 50k expire 30m
   stick on src
   timeout connect 30s
   timeout server 30s
   http-reuse never
   server plex 192.168.100.212:32400

backend guacamole
   mode http
   balance source
   stick-table type ip size 50k expire 30m
   stick on src
   timeout connect 30s
   timeout server 30s
   http-reuse never
   server guacamole 192.168.100.201:8084
"

How to translate this to OPNsense??? I tried for a few days, but it's beyond my knowledge.

There are a lot of countries or even more and more hotels, where only tcp 80 and 443 are opened in their wifi's or LAN's.

Therefore I'm also highly interested how to configure hyproxy to seperate openvpn traffic from webtraffic. Googling around brings up this: https://community.openvpn.net/openvpn/ticket/1352

" HAProxy is perfectly capable of proxying and load balancing OpenVPN in TCP mode, and to share a single listening port with OpenVPN and HTTPS sites. I have used this configuration for years.

To distinguish OpenVPN traffic from TLS traffic, use the following combination HAProxy ACL conditions in a HAProxy frontend

!{ req.ssl_hello_type 1 } !{ req.len 0 }

To distinguish SSH traffic from TLS traffic, use the following combination of HAProxy ACL conditions in a HAProxy frontend:

!{ req.ssl_hello_type 1 } { req.len 0 }

A HAProxy backend can be used to load balance multiple servers. Use TCP mode.

A barebone example configuration is given here:

​https://gist.github.com/zukka77/a5ddb8d81ef9a82e2ff797e3a578c97e

Furthemore, PROXY protocol is protocol agnostic, and could therefore perfectly well be implemented in OpenVPN (Community version). Read more here:

​https://www.haproxy.com/blog/haproxy/proxy-protocol/

PROXY protocol support in OpenVPN would be very welcome, since it will allow OpenVPN servers to know the real IP addresses of connecting clients."

Further more:

https://gist.github.com/zukka77/a5ddb8d81ef9a82e2ff797e3a578c97e

"frontend ssl
    mode tcp
    bind 0.0.0.0:443 name frontend-ssl
    option tcplog
    log global
    tcp-request inspect-delay 3s
    tcp-request content accept  if  { req.ssl_hello_type 1 }
    use_backend main-ssl        if  { req.ssl_hello_type 1 }
    use_backend ssh             if  !{ req.ssl_hello_type 1 } { payload(0,7) -m bin 5353482d322e30 }
    use_backend openvpn         if  !{ req.ssl_hello_type 1 } !{ req.len 0 }
    use_backend ssh             if  !{ req.ssl_hello_type 1 } { req.len 0 }


backend main-ssl
    mode tcp
    server main-ssl 127.0.0.1:8443

backend openvpn
    mode tcp
    server openvpn-localhost 127.0.0.1:1194

backend ssh
    mode tcp
    server ssh-localhost 127.0.0.1:22
"

Let's try together to figure out how this can be translated in OPNsense haproxy. As pre-requisite a openvpn server is running configured to listen on port 1194 and ready to connect to roadwarriors.

In haproxy:

1. I assume it has to be a condition created including !{ req.ssl_hello_type 1 } !{ req.len 0 }
2. a rule is needed which includes the condition and directs the traffic to the vpn server via the vpn backend.
3. a real openvpn server has to be setup
4. a backend vpn is needed

As the SNI_frontend sends most of its traffic to SSL_backend, has this to be integratet in the SNI_frontend or is a new i.e. VPN_frontend needed?

At this point I need help to step further. How exactly has this to be setup? Where are the gurus to get this on the way? IMVHO a lot of people would appreciate a solution.

regards,
stefan

This is (as today) still working:

I just ran a test with https://www.spamhaus.org/drop/drop.txt and it seems to work fine

You can check the alias under firewall/diagnostics/aliases

But:

For long-term users of the DROP files in text format, we recommend you update your configuration with the above JSON files as soon as your cycles allow. If you require continued long-term use of a text file, the jq command can always be used to convert the JSON.

N.B. The text files are still being populated however, in time, these will be deprecated; users will be notified with ample notice before deprecation takes place.

Question: Did anybody already implement the https://www.spamhaus.org/drop/drop_v4.json? I can't get it working.

Thank's for any reply.
stefan

OPNsense is up-to-date -->

OPNsense 24.1.2_1-amd64
FreeBSD 13.2-RELEASE-p10
OpenSSL 3.0.13

Firefox: 121.0 (64-bit), archlinux (doesn't matter, latest update on windows brings up the same issue)

DEFAULT in FF: security.ssl.enable_ocsp_stapling = true

--> leads to no access on any pages with certs following the tutorial. At least if pages are secured to local access only. I assume, same error for public access.

Changing the default in FF to false gives access back.

Made a few changes:

Did a roll back to

OPNsense 23.7.12_5-amd64
FreeBSD 13.2-RELEASE-p7
OpenSSL 1.1.1w

For all certs I changed to key lenght 2048. OCSP must staple "off". Renewed all certs and deployed to the servers. Now on all clients FF and TB are working again with no errors.

Adding local and public subdomain rules in public services HTTPS_frontend are not working as expected in my setup. Adding in option pass through

acl lan_vpn src 192.168.x.x/24
acl lan_vpn src 10.0.x.x/24
http-request deny if ! lan_vpn

is working. Access from public is not possible - as intended. Maybe it helps someone.

@thehellsite: thx very much for this great tutorial.

regards,
stefan

OPNsense is up-to-date -->

OPNsense 24.1.2_1-amd64
FreeBSD 13.2-RELEASE-p10
OpenSSL 3.0.13

Firefox: 121.0 (64-bit), archlinux (doesn't matter, latest update on windows brings up the same issue)

DEFAULT in FF: security.ssl.enable_ocsp_stapling = true

--> leads to no access on any pages with certs following the tutorial. At least if pages are secured to local access only. I assume, same error for public access.

Changing the default in FF to false gives access back.

Question: anyone else with this experiance? Something wrong in my config? Did I overlook something? I tried to follow exactly the tutorial (not using wild card certs). Did work before the last update of the certs... OCSP-server down? If so, does OCSP making sense for servers meant for internal access only? Not at all for me. Even for public access - if an OCSP server is blocked or down, no access to a server would be possible. No control to third party (man in the middle) confirm. Does this really make sense?

Opinions welcome.

regards,
stefan

Duhhh, stupid me!

I copied a certificate and forgot to change the automation.

Sorry for the whistle, all working as expected.

[Here is what works:]

Well, I know old topic, old thread.

Anyway, after searching and googling for days I have to push this up hoping someone jumps on.

Here is what works:

From the cli of the opnsense:

#:/local/opnsense/scripts/OPNsense/AcmeClient # ./upload_sftp.php --log --host=192.168.xx.15 --user=xx test-connection
INFO: Logging to stdout enabled
INFO: No host key specified, using existing known_hosts entry for '192.168.xx.15'
INFO: SFTP: Connected to 192.168.xx.15.
INFO: SFTP: sftp> pwd
INFO: SFTP: sftp> ls -la
INFO: SFTP: sftp> put '/tmp/sftp-upload-khpkxO' 'sftp-upload-khpkxO'
INFO: SFTP: Uploading /tmp/sftp-upload-khpkxO to /home/xx/sftp-upload-khpkxO
INFO: SFTP: sftp> rm '/home/xx/sftp-upload-khpkxO'
INFO: SFTP: Removing /home/xx/sftp-upload-khpkxO
INFO: SFTP: sftp> exit
{
    "actions": [
        "connecting",
        "connected",
        "upload-testing",
        "upload-tested"
    ],
    "success": true,
    "remote": {
        "host": "192.168.xx.15",
        "port": 22,
        "user": "xx",
        "path": "/home/xx"
    }
}

and:

#:/usr/local/opnsense/scripts/OPNsense/AcmeClient # ./upload_sftp.php --log --certificates=mail.xx.de --host=192.168.xx.15 --user=xx
INFO: Logging to stdout enabled
INFO: No host key specified, using existing known_hosts entry for '192.168.xx.15'
INFO: SFTP: Connected to 192.168.xx.15.
INFO: SFTP: sftp> pwd
INFO: SFTP: sftp> cd '/home/xx/mail.xx.de'
INFO: SFTP: stat remote: No such file or directory
INFO: Creating remote directory: /home/xx/mail.xx.de
INFO: SFTP: sftp> pwd
INFO: SFTP: sftp> mkdir '/home/xx/mail.xx.de'
INFO: SFTP: sftp> cd '/home/xx/mail.xx.de'
INFO: SFTP: sftp> pwd
INFO: SFTP: sftp> ls -la
INFO: SFTP: sftp> put '/tmp/sftp-upload-f1fIwZ' 'ca.pem'
INFO: SFTP: Uploading /tmp/sftp-upload-f1fIwZ to /home/xx/mail.xx.de/ca.pem
INFO: SFTP: sftp> put '/tmp/sftp-upload-6ytT6R' 'cert.pem'
INFO: SFTP: Uploading /tmp/sftp-upload-6ytT6R to /home/xx/mail.xx.de/cert.pem
INFO: SFTP: sftp> put '/tmp/sftp-upload-PZO74I' 'fullchain.pem'
INFO: SFTP: Uploading /tmp/sftp-upload-PZO74I to /home/xx/mail.xx.de/fullchain.pem
INFO: SFTP: sftp> put '/tmp/sftp-upload-SgMDcZ' 'key.pem'
INFO: SFTP: Uploading /tmp/sftp-upload-SgMDcZ to /home/xx/mail.xx.de/key.pem
INFO: SFTP: sftp> exit

Further:

On the target server:

ls -la mail.xx.de/
insgesamt 28
drwxr-xr-x 2 xx xx 4096 29. Dez 19:01 .
drwx------ 7 xx xx 4096 29. Dez 19:01 ..
-rw------- 1 xx xx 3750 29. Dez 19:01 ca.pem
-rw------- 1 xx xx 1537 29. Dez 19:01 cert.pem
-rw------- 1 xx xx 5287 29. Dez 19:01 fullchain.pem
-rw------- 1 xx xx  288 29. Dez 19:01 key.pem

All there - the let's encrypt cert was copied.

Question: why on heavens earth does this not work using the gui acme automation? What's wrong here?

I'm stuck. Any help is greatly appreciated. 

OPNsense 23.7.7_3-amd64
FreeBSD 13.2-RELEASE-p3
OpenSSL 1.1.1w 11 Sep 2023
ACME Client 3.19

I reset the acme plugin and created a new cert and a new automation. SFTP upload test is giving no errors.

But a manual run of an automation (ACME client --> Services: ACME Client: Certificates --> run automations causes in following error:

AcmeClient: automation not found: b2a9610b-7fb3-4554-bf4e-09eaa77c65eb

No matter after copying the automation in a new one, or deleting the automation and creating a new one. All new or copied automations always have the same ID b2a9610b-7fb3-4554-bf4e-09eaa77c65eb.

How to investigate? Any advice is appreciated.

Sorry for the whistle...

A reboot did it.

regards,
stefan

OPNsense 23.7.7_3 - up-to-date

For tests I installed the nginx and the acme plugin. I changed for the gui access the https port to http, and after uninstall back to https port as before.

After uninstalling the plugins the gui is not reachable. Nor http or https.

I've access to cli. Need help to find the right track back. Where to investigate? I assume there are orphaned dependencies left over which may interfere.

Any help is greatly appreciated.

stefan

Thank you Maurice, it's a little tricky, but I got it to work.

It's really - and ONLY - meant to use a WAN connection as a failover if the ISP is down for a few hours.

For the test I used a nano image on a USB flash drive on my laptop. Connecting via smartphone does work if blocking private networks on the WAN-interface is disabled. The phone passes an IP of the private range to the WAN interface. The firewall is up and if imported a backup from the real OPNsense everything on the LAN works as expected. After connecting the phone to the laptop and assigning the ue interface, I reloaded the services. I did this all on the console. Well - later I disabled zenarmor and also IDS in the web-gui ... At least the allowed clients in the LAN are able to reach the internet.

We have one static IP for the WAN. Behind the OPNsense is a Nethserver running our own email-server. If the static IP is not reachable, you'll not be able to send (usually the dynamic IP from the phone is blacklisted) or receive any email with the email server. If you can't wait receiving and sending email until your ISP has fixed the problem, a solution could be configuring temporarily an email relay on the server. And an email account at your webhoster space for a catchall account of your domain. You have to adjust the DNS records for your domain... and reverse it later as it was before. Or you could use a webmail portal to communicate and send your email.

I don't want to do this - as a business customer we do have a reaction time of 8 hours 7/24. We can hold this... So all this is meant to keep the LAN clients connected to the internet.

Thank's again for pointing me in the right direction.

regards,
stefan

Thank you for hopping on and your reply.

I'll give that a try and will report.

regards,
stefan

Sorry to push this up again.

Nobody using an android gateway in usb tethering mode?