Messages

I forgot to supply the new VPN network on the other side.
But it did not help anything.

Hello,

since a while it is mentioned that DHCP and OpenVPN have legacy status and, after pushing investigations for too long, i started to look into this.


I get it working although routes are not coming through.

They get pushed to the client (linux as well as windows) but only the closest (where the vpn is hosted) is working.

My main location (where's the OPN) is 10.80.0.0/16, the remote location is 10.100.0.0/16 (this gets pushed to the client but not doing anything).


Any adea? I tested this on 2 locations with the same results.

24.7.10


Thanks!


EDIT:

it was a retour route on a wireguard tunnel which was forgotten

Hi,

I'm using truenas scale as a hypervisor for OPN as VM
Giving them multiple cores, 2GB RAM, virtio NIC, latest OPN and tested on different platforms:

System1: and old kabini quad core @ 2.050 MHz
System2: an older Intel Xeon E5-2675 16 core @ 1.800 Mhz
System3: relative new AMD Ryzen 5 3400G 4 core @ 4000 Mhz

My Gbit internet readings are at:
System1: 350Mbit
System2: 750Mbit
System3: 975Mbit

System 1 and 2 get double the performance when providing multiple threads/core-counts but are limited to the readings above while the 3rd system can handle the Gbit speed with even 1 thread/core.

Even when i quadruple system 1 or 2, it does not matter. Readings stay the same and from the CPU indicator, on the mainpage of truenas, it looks like a single thread using 100% core time. Also getting multiple TCP streams does not affect the maximum speed, it stays limited.

Is this explainable by the CPU's frequency alone or should go to the tuning pages of BSD? I'm fine with my 750Mbit though, but just curious.


Thx for any substantiated insights

Looks like my Aliasses were blocked by resolving issues, this way the VPN could not be made.


The unassigned interfaces is something that i see on multiple installations.

Will rebuild it any time soon. Looks like header mismatch in the config.file

Hi,

2 weeks ago i upgraded my HA config tot 21.7.7 and today i am experiencing some issues.

• One of my mainswitches just disappears and reappears from ping requests from my zabbix interface. When it happens, it's not possible to ICMP the thing, only from that same VLAN. Happens every UNKNOWN
  


• Another issue, a UDP-state to my other branch does not close so the VPN does not reconnect. A reboot fixed it. This never happened before.


• A third issue, under interfaces/overview, all the physical interfaces appear as unassigned.

I see there is a new upgrade to 22 series. An upgrade at a 3rd opnsense appliance did not fix the "unassigned" issue. I will try a restore config on 22 and compare the interface section at xml file.

I found a patch at PFsense: https://redmine.pfsense.org/issues/12698
Could this cause my issue(s)?


Thanks in advance

Figured to boot in singe mode.

mount -o rw /

giving the command:

"opnsense-shell password" it provides to turn off OTP.

:)

Adjusted the cloud-init image to know about the manual proxy-server instead of transparant.

Maybe a simple answer for it, i lost my phone with the authenticator app.

Anyone knows how to login to the root account and re-establish it?

Thx in advance

Actually, i gave up on this.

Isn't there any other way to avoid those certificates?

I want to load some ready cloud-init images which do not have the certificate or even a browser.

After some wiresharking, digging and searching we found the problem.

If you enable the DHCP service on a (clients) interface the DHCP Relay service also starts at the interface behind which it will find the DHCP server. But in order to do that the firewall needs to know before hand where it can find the DHCP server.

Opnsense forwards DHCP discover pakkets with the IP address of the outgoing interface as source IP.
If Opnsense does not also start the DHCP Relay service on its outgoing interface it will forward DHCP Discover pakkets to the configured server. The DHCP server will respond with a DHCP Offer for the (client) network from which the pakket originally came. But Opnsense will not process the DHCP Offer on its outside interface and relay it back to the original (client) network.

The problem was fixed with a static route to the DHCP server over the WAN interface. Now Opnsense starts the DHCP Relay service on the interface for which you would like to enable DHCP Relaying AND the outside interface to process DHCP Offers.

We have a problem with DHCP relay over our WAN interface of a branch office in our network.

Our setup is 2 OPNsense firewalls/routers on 2 sites and site 1 is the upstream router for site 2. The internetbreakout is on site 1. Between site 1 and site 2 is 172.16.253.0/30 subnet and no NAT

INTERNET <--> OPNsense1 <--> OPNsense2

On both sites we have DHCP server but we would like to turn off the DHCP server on site 2 and relay DHCP requests to the DHCP server on site 1. This is not possible because the DHCP server is behind the WAN interface of OPNsense2...

WHY??

[The following error was encountered while trying to retrieve the URL: /Invalid URLSome aspect of the requested URL is incorrect.Some possible problems are:Missing or incorrect access protocol (should be http:// or similar)Missing hostnameIllegal double-escape in the URL-PathIllegal character in hostname; underscores are not allowed.]

Hi,

i'm trying to follow the webproxy setup.
Manually the webproxy works with manual settings to 3128 but now i want to change it to transparent.

My setup is:

client @ vlanX (10.80.24.0/24)
opnwebprxy  @ vlanY (10.80.25.32)

Through opngateway (10.80.5.1) i try to create a NAT rule to forward http & https to that 10.80.25.32.
The squid answers:

The following error was encountered while trying to retrieve the URL: /
Invalid URL
Some aspect of the requested URL is incorrect.
Some possible problems are:
Missing or incorrect access protocol (should be http:// or similar)
Missing hostname
Illegal double-escape in the URL-Path
Illegal character in hostname; underscores are not allowed.


"Transparent" is already enabled on squid.
I did not enable the CA yet but im first testing it with a non-ssl site.


So: @
interface vlanX
ipv4tcp
source: vlanXnet
source-range: any any
dest: any
dest-range: http http
redirect: 10.80.25.32
target-port: 3128
enable nat-reflection
rule NAT

Moved the rules on the top as i've read this somewhere.

Any idea what i could be missing?

Thanks

Wow.... after manually copying all my config to my other box i experienced the same.

I found that in de aliases is something wrong after deleting whole parts until i got it working.


Strange thing (i don't know yet) but it has to be a limit of aliases or a misplaced character.

Anyway i did not need those aliases anymore...

Happy user again  :-)

Strange,

i took the day to rebuild the whole thing from scratch... having the same issue.
It is like i'm not understanding something..

The box itself has a WAN IP address through dhcp @ vlan34, it can download packages (like letsencrypt) but it does not function as the gateway for my assigned subnets.

It is checked as the default gateway, ip monitoring has been enabled & re-disabled.... no luck with this.

Woops.... and then i pressed "update" to 18.7.1 .... broken again :-(

It was working though... at 18.7 :-(


Email says:

There were error(s) loading the rules: /tmp/rules.debug:153: macro '500' not defined - The line in question reads [153]: nat on re0_vlan34 inet from (re1:network) to any port $500 -> re0_vlan34:0 static-port # Automatic outbound rule

Should i maybe recreate the re0_vlan34  interface??