Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
#
# Automatically generated configuration.
# Do not edit this file manually.
#
global
uid 80
gid 80
chroot /var/haproxy
daemon
stats socket /var/run/haproxy.socket group proxy mode 775 level admin expose-fd listeners
nbproc 1
nbthread 4
hard-stop-after 60s
maxconn 10000
tune.ssl.default-dh-param 4096
spread-checks 2
tune.chksize 16384
tune.bufsize 16384
tune.lua.maxmem 0
log /var/run/log local0 debug
lua-prepend-path /tmp/haproxy/lua/?.lua
defaults
log global
option redispatch -1
maxconn 5000
timeout client 30s
timeout connect 30s
timeout server 30s
retries 3
default-server init-addr last,libc
# autogenerated entries for ACLs
# autogenerated entries for config in backends/frontends
# autogenerated entries for stats
# Frontend: 0_SNI_Frontend (listening on 0.0.0.0:80 and 0.0.0.0:443)
frontend 0_SNI_Frontend
bind 0.0.0.0:443 name 0.0.0.0:443
bind 0.0.0.0:80 name 0.0.0.0:80
mode tcp
default_backend SSL_Backend
# tuning options
timeout client 30s
# logging options
# Frontend: 1_HTTP_Frontend (Listening on 192.168.1.50:80)
frontend 1_HTTP_Frontend
bind 192.168.1.50:80 name 192.168.1.50:80 accept-proxy
mode http
option http-keep-alive
option forwardfor
# tuning options
timeout client 30s
# logging options
# ACL: NOSSL_Condition
acl acl_60f9d6d0118252.11362730 req.ssl_ver gt 0
# ACTION: HTTPtoHTTPS_Rule
http-request redirect scheme https code 301 if !acl_60f9d6d0118252.11362730
# Frontend: 1_HTTPS_Frontend (listening on 192.168.1.50:443)
frontend 1_HTTPS_Frontend
http-response set-header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
bind 192.168.1.50:443 name 192.168.1.50:443 accept-proxy ssl curves secp384r1 no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384 ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/60f9db5421ce96.24863488.certlist
mode http
option http-keep-alive
option forwardfor
# tuning options
timeout client 15m
# logging options
# ACTION: Public_Sub_MapRule
# NOTE: actions with no ACLs/conditions will always match
use_backend %[req.hdr(host),lower,map_dom(/tmp/haproxy/mapfiles/61698448328ff6.66158166.txt)]
# Backend: SSL_Backend ()
backend SSL_Backend
# health checking is DISABLED
mode tcp
balance source
# stickiness
stick-table type ip size 50k expire 30m
stick on src
# tuning options
timeout connect 30s
timeout server 30s
server HAP_VIP 192.168.1.50 send-proxy-v2 check-send-proxy
# Backend: TruePlex_Backend ()
backend TruePlex_Backend
# health checking is DISABLED
mode http
balance source
# stickiness
stick-table type ip size 50k expire 30m
stick on src
# tuning options
timeout connect 30s
timeout server 30s
http-reuse safe
server TruePlex 192.168.1.12:32400 ssl verify none
YesIf anyone can share the ubench -cs output I can provide a throughput estimate.
@TheHellSiteI was just about to write you exactly this!
I think the problem is with the SNI frontend. Here the SSL backend is specified as the default backend. He doesn't even look at the MAP file. he forwards everything to the SSL backend. When I set the openvpn backend as default Backend for a test in the SNI frontend, openvpn work but the other things not.
do you have an idea how I can solve this?
Your reply confirmed my guess.
Looking through the manual pages of HAProxy it seems that the "Default Backend" setting can only be overwritten by a "Use Backend" rule! Which a "Use map file" rule isn't able to.
https://www.haproxy.com/de/blog/the-four-essential-sections-of-an-haproxy-configuration/
But I can't imagine that this is the intended behaviour.
Anyways... you simply need to create a VPN_condition "host starts with vpn" and a "use backend OPENVPN_backend if VPN_condition=true" rule.
Add this rule to the SNI_frontend and set the default backend back to the SSL_backend.
Hi,
Just add some comments reading up on this. I am not sure you are quite familiar to know what OPNSense really is... It's a firewall first and not a router.
Now on some things for others to know in regards to DHCP. It is mandatory for any organization to have a local DHCP. No one under any circumstances ought to use DHCP relay across a WAN interface EVEN if it's L2 ethernet (YOU DON'T OWN THE WIRE!!!) To add to this, I can create an AToM (Any Transport over MPLS) across Frame/ATM/ISDN and give you a L2 ethernet. So, NO! you got no clue what you got... LOL
As for other Routing features, if anything not working, please file your complaints to https://frrouting.org/.
you do have one or two nice complaints, but all others... Meh!
edit: just outta curiosity, what did you end up replacing OPNSense with?
Hi lilsense,
First of all thanks for the comment.
Few points that you've mentioned - DHCP relay - do you really think that feature should not work? I'm coming from the Enterprise and Service provider segments and for the last almost 20 years I haven't seen a vendor where DHCP relay doesn't work. Technically it is so simple - just listen on broadcast DHCP messages and forward it to an unicast destination (based on the configured unicast IP and routing table) and vice versa (and of course do a slight modification of few DHCP fields in the packet format)
Regarding the design decision to rely on central DHCP server in the HQ and not on local one - it really depends. Yes, I agree it is not wise all hosts in a branch office to lose IP addresses and not to be able to communicate locally, because of WAN failure. But why you believe this is the case here? As I said - the setup I'm working on is quite simple, so simple that all hosts (literally few) in each remote location are configured with static addressing. The DHCP relay was intended to be used only the deployment phase (PXE).
Regarding the firewall vs routing platform - I'm trying to accomplish really simple things which are widely available in the last 20 years in open source implementations like Zebra/Quagga/FRR! I'm not talking about MPLS and its applications like L2VPNs, L3VPNs, TE, DiffServ Aware TE, AToM, CsC, Inter-AS options (like A,B,C,AB). I'm not talking about segment routing. I'm not talking about DMVPN or vendor specific solutions like GetVPN, FlexVPN, etc)
I'm not talking about various SD-WAN solutions that each vendor (including Firewall Vendors) provides nowadays. I'm not talking about really specific BGP and OSPF features like MP-BGP transporting IPv6 over IPv4 AFI or vice versa, selective BGP next-hop address tracking, BGP confederations, BGP as-path ignore or relax, complex multi-area OSPF area stub and NSSA areas, OSPF Forward Address tricks, OSPF Type7-to-Type5 translator selection, OSPFv3 Authentication Trailer and so on. All I'm talking about is a CORE FUNCTIONALITY which is not missing from FRR (yes, it's there, it was there in Quagga, it was there even in Zebra in 2004), but it is missing in OpnSense FrontEnd. Tell me a single firewall vendor which doesn't support IBGP Route Reflector? (is it a good design of using a firewall as a BGP RR is completely different story). An year ago it was even not possible to change the keepalive/holdtime timers for the BGP session via GUI and we had to rely on the peer device to do it!
Going back to the firewall functionality - the only reason of having less complaints for it in the list above is just because the setup I'm using is really, really simple. And actually it cannot evolves to more complex one, definitely not with OpnSense. I can't imagine dealing with more than 100 rules and with more than 5 interfaces! Imagine I need to move a rule to the middle or rearrange the rules a little bit.... I'm pretty sure that editing the pf.conf with VI will be much faster than trying to accomplish this with the Front-End. And of course - you can still generate a completely invalid rule with the Front-End and try to insert it (the same thing I can do with the text editor,right?). I'm also grateful that I don't need to play with NATs in that deployment.
What did I end up replacing OPNSense with - I haven't replaced that yet, and the only reason for that is the minority of changes expected after the go-live.
My thought process when we selected OpnSense was to check the support for the required features - does it support DHCP relay - Yes (is it working for me - NO, but that's not written anywhere), does it support dynamic routing - Yes (is it working for me as it is - NO and again that's not documented), does it support HA - Yes (does it for active-active - No, again not documented), does it support VLANs - yes (do I need to interrupt the traffic when I need to add additional VLAN - yes, and again lacks in the documentation)
For future low cost projects I would definitely prefer a fresh Linux based distribution with iproute2, frr, iptables/nftables. At least I'll be able to achieve the routing part. For firewall part - probably I'll go with OpenBSD (In case I can't make the HA as I want in linux). Will it be with a shiny web based UI - No, it won't. Will it work - Yes, it will. Will I have to spend time debugging Front-End and Back-End interaction just to generate a simple config file for 3rd party open source product usually with a good documentation and tons of examples in Internet - no.
