Messages

1

20.1 Legacy Series / Re: Reply-to on WAN by default is bogus

« on: January 12, 2021, 11:40:21 am »

I believe oddjarle's problem is different than the OP. The reply simply travels via default route. removing the gateway from wan won't change that, will it? Maybe continue here:

https://forum.opnsense.org/index.php?topic=20843.0

2

20.1 Legacy Series / Re: Reply-to on WAN by default is bogus

« on: January 11, 2021, 11:10:38 pm »

I have a similar issue as @oddjarle.

Is there any solution to this problem?

3

20.7 Legacy Series / Re: Routing: How to force OPNsense to route HAproxy replies via originating gateway?

« on: January 11, 2021, 10:55:41 pm »

I believe this person has the same/similar issue:

https://forum.opnsense.org/index.php?topic=15900.msg79646#msg79646

4

20.7 Legacy Series / Routing: How to add custom reply-to to specific traffic on non-wan interface?

« on: January 11, 2021, 01:34:47 am »

My OPNsense sits behind two other routers. I have HAproxy installed and configured. I want to offer some services via WAN/router 1 and some via WAN/router 2.

• request hits router 1 or 2
• request is port forwarded to OPNsense/HAproxy
• HAproxy speaks to backend
• HAproxy's response is then forwarded to the client via the default gateway (router 1)!

Added difficulty: Router 2 sits in LAN and not on a separate WAN interface of the OPNsense.

How can I achieve that OPNsense sends response via correct gateway/router?

5

20.7 Legacy Series / Re: HAProxy & Firewall

« on: October 12, 2020, 12:25:08 pm »

Thanks so much for your input. There were two issues:

• The rule was indeed bypassed by another rule (HAProxy is running on a second IP on WAN), so a rule with DST "WAN address" bypassed it (although I though that this only contains the primary IP of the interface)
• The alias needs really long to be reloaded in the firewall rules. So the alias updates just fine, but then it takes roughly 1-2 minutes until the IP is blocked.

Do you by any chance know on how to trigger this manually, could only find the endpoint "reconfigure" but I'm not sure that is correct.

6

20.7 Legacy Series / [solved] HAProxy & Firewall

« on: September 27, 2020, 10:53:48 pm »

I was playing around with Fail2Ban and wanted to block IPs that fail to auth with a HAProxy backend server. So I created an external alias and Fail2Ban updates that alias. So far so good. However, when I add a firewall rule to block src=ips in alias nothing happens. I had a look at the log and it seems like running HAProxy on publicip:port completely bypasses the firewall. There is nothing in the firewall logs but HAProxy logs the connection. Is that correct?

So to work around this I would need HAProxy to bind to another IP and make a port forward from the public IP/interface?

7

20.7 Legacy Series / Re: MultiWAN: delay restoring of default WAN

« on: September 23, 2020, 04:43:57 pm »

No, never adjusted the thresholds. Will try that. Thanks for your input.

8

20.7 Legacy Series / MultiWAN: delay restoring of default WAN

« on: September 21, 2020, 10:12:47 pm »

We use MultiWAN in a failover config. When the main line becomes a bit unstable we repeatedly had the issue that the failover was flipping back and forth between the two WAN interfaces. Like WAN1 goes down for a couple of minutes, failover to WAN2, WAN1 is again good for a couple of minutes so back to WAN1 and so forth. Is there a way to delay this? Like if we failover to WAN2 I want to the system to stay put for at least 15 minutes on WAN2 no matter what before going back to WAN1? Can Alert Interval be used for this (couldn't find anything in the docs)?

9

German - Deutsch / Re: IPsec mit VTI, kein automat. Start bei Datenverkehr

« on: September 18, 2020, 02:37:52 am »

Hast du das mit dem NAT lösen können? Ich stehe nämlich vor genau dem gleichen Problem.

10

20.7 Legacy Series / Re: [SOLVED] Problems with HAProxy plugin

« on: August 17, 2020, 09:23:01 am »

I understand that both servers run both website, correct?

Did you make sure that in rule ["myservice_sni"] you changed the "Logical operator for conditions" to "OR"? It is obviously not possible to match both conditions at the same time...

11

20.7 Legacy Series / Re: [SOLVED] Problems with HAProxy plugin

« on: August 16, 2020, 07:14:48 pm »

This should work for any TCP-based SSL/TLS encrypted service in passthrough (HAProxy: TCP) mode... It does NOT work for STARTTLS!

In this example I use TCP port 443.

• HAProxy plugin: Create "Real Server" (enter name, IP/FQDN and port number if different from 443, the rest can be left at default)
• HAProxy plugin: Create "Backend Pool" (enter name, set mode to TCP and select the real server from step 1)
• HAProxy plugin: Create "Condition" (enter name ["traffic_ssl"], condition type is "custom condition (option pass-through)" with value "req_ssl_hello_type 1")
• HAProxy plugin: Create "condition" (enter name ["myservice_sni"], condition type is "SNI TLS extension matches (TCP request content inspection)" with value "myservice.example.com" or whatever your FQDN is)
• HAProxy plugin: Create "Rule" (enter name ["request_inspect_delay"], select no condition, function is "tcp-request inspect delay" with value "5s" or whatever suits you)
• HAProxy plugin: Create "Rule" (enter name ["request_content_accept_ssl"], select condition of 3 ["traffic_ssl"], function is "tcp-request content accept")
• HAProxy plugin: Create "Rule" (enter name ["myservice_sni"], select condition of 4 ["myservice_sni"], function is "Use specific backend pool" with your pool from 2)
• HAProxy plugin: Create "Public service" (enter name ["https_passthrough"], choose a listen address [":443" for all], type is "TCP" and select the 3 rules created earlier)
• HAProxy plugin: Enable plugin or test/apply
• Firewall: allow incoming traffic to WAN (address) or whatever for TCP port 443.

That works at least for me. If you have double NAT you would need to disable port randomization for the proxied port...

Does that help you?

12

20.7 Legacy Series / Re: [SOLVED] Can't get port forwarding to work anymore!

« on: August 14, 2020, 09:19:48 am »

I did have 20.7.0 installed and the mode is set to manual. The upgrade to 20.7.1 fixed the particular issue without me changing/adding any rules. So either the reboot changed it (which I doubt since I did that before as well) or the fixes in 20.7.1... Anyway, issue is solved for me and my rules work now as intended.

13

20.7 Legacy Series / Am I misunderstanding "static port" (port randomization) wrongly?

« on: August 13, 2020, 10:47:18 pm »

I have the following setup:

Internet -> Speedport Router -> OPNsense -> Server

The Speedport cannot do static routes so this is a double NAT scenario. I port forward TCP 8443 from Internet to OPNsense in the Speedport and from WAN-Network to Server in the OPNsense.

The reply of a request to the server is by default subject to source port randomization and the Speedport would drop it.

I now added a rule to Outbound NAT setting static port for the traffic originating from the server (and the forwarded port) (1).

However, the source port was still subject to randomization.

I had to set the source address to the WAN address of the OPNsense (2).

Is this normal behaviour? I really would have expected it to work with the first rule and not the second.

Because my next question would be on how to disable port randomization for a whole VLAN (for SIP to work in double NAT environment) if the first rule does not work? Or is this just a specific behaviour if port forwarding is involved?

Thanks for enlightening me.

14

20.7 Legacy Series / Re: Can't get port forwarding to work anymore!

« on: August 13, 2020, 10:32:41 pm »

Just installed 20.7.1 and that fixed my issue (at least partly). Replies from LAN/VLANs travel now back to WAN.

However, port randomization confuses the Speedport router. I had to add rules to outbound NAT to enable static port on the forwarded ports. Strangely enough, I had to do this with source any instead of only the server... but that is maybe a lack of understanding from myself.

15

20.7 Legacy Series / Re: Problems with HAProxy plugin

« on: August 13, 2020, 11:48:37 am »

Looks like adding the following two lines/options to frontend config solves the issue (advanced mode):

Code: [Select]

tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }

Of course you better create conditions/rules for this since it avoids an warning during config check and integrates more nicely with the GUI of the plugin