Messages

1

22.7 Legacy Series / Edit route, gateway drop down missing entry

« on: October 12, 2022, 10:28:11 pm »

I had strange issue, which resolved after reboot.
I added gateway and than wanted to add static route.
In Edit route window, under gateway drop down, there were only old gateways (DHCP WAN, ...), but not new one.
Finally I rebooted router and no drop down is updated, and also if I add another gateway it is instantly available in drop down.

Did anyone else had same issue before ?

2

Virtual private networks / MPLS forward or terminate on OPNsense box.

« on: September 28, 2021, 12:21:39 pm »

I received interesting request... To terminate MPLS on router in our case OPNsense.
I am looking for MPLS in documentation and there is nothing about it, am I wrong ?

I am not looking in MPLS terminated on ISP end but OPNsense used as part of MPLS network (as VyOS and Mikrotik can do).

3

19.7 Legacy Series / Re: Slow WebGUI even when downloading packet capture

« on: November 04, 2019, 02:51:04 pm »

Today I rebooted and problem is still unsolved.

Problem is still present even on update to version:
OPNsense 19.7.6-amd64
FreeBSD 11.2-RELEASE-p14-HBSD
OpenSSL 1.0.2t 10 Sep 2019

4

19.7 Legacy Series / Re: Slow WebGUI even when downloading packet capture

« on: October 23, 2019, 09:56:57 am »

Hi, I installed mentioned plugin and it did not make any difference for me. I installed it on both boxes and web interface have same responsiveness.

It is not mentioned but should I reboot it ?

Best regards, Robi

5

19.7 Legacy Series / Re: Slow WebGUI even when downloading packet capture

« on: October 22, 2019, 10:03:05 am »

In my case it is same behaviour php-cgi is taking whole core(s).

I hardly find some pages that loads normaly and these are:
Services/Monit/Settings
Services/Monit/Status
Services/Unbound DNS/Statistics
Services/Web Proxy/Administration
Services/Zabbix
Power/Reboot
Power/Poweroff

I updated system to latest version from first post and results are still the same.
Current version
OPNsense 19.7.5_5-amd64
FreeBSD 11.2-RELEASE-p14-HBSD
OpenSSL 1.0.2t 10 Sep 2019

Same behaviour I have on master and slave box.

6

19.7 Legacy Series / Slow WebGUI even when downloading packet capture

« on: October 14, 2019, 12:15:54 pm »

On my HA setup I have very strange situation where I can not resolve slow WebGUI problem.
DNS resolving works normally, updates work normally but when I navigate from one to another page it takes like 10s.
Even if I click to download .cap file after finish of packet capture it takes 11.25s before it starts (packet capture file is 24Byte in size)
I was already looking into iostat and top but nothing special that will help me with resolution.

My version:
OPNsense 19.7.3-amd64
FreeBSD 11.2-RELEASE-p14-HBSD
OpenSSL 1.0.2s 28 May 2019

A will update as soon as possible but this is probably not problem because we have problem with Slow interface since we get this server in production.
I checked disks and health is OK.
Average load is 2.00 and CPU is Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz (8 cores)

Does anybody have any suggestion where can I start debugging it?

Best regards, Robi

7

19.1 Legacy Series / Re: HA + WAN in private network + Outbound NAT + IPsec and some problems

« on: June 01, 2019, 10:35:37 am »

After update to 19.1.8 we noticed that CARP did not fall back to master firewall and as mentioned in some other thread, reboot of master after "Leave persistent CARP maintenance mode" did help.

However, IPsec still showing only 1 of 4 CARP IPs that we want to be available for same interface for IPsec.

And we noticed problems regarding config synhronisation from master to slave.
DHCP leases and Suricata (Intrusion Prevention) is Synching only with manual sync with pressing perform synhronisation.

8

19.1 Legacy Series / HA + WAN in private network + Outbound NAT + IPsec and some problems

« on: May 30, 2019, 01:42:16 pm »

Hello all,

We have HA pair of routers and Cisco pair of Switches in front if it.
On Cisco L3 Switches we also run BGP and there is no NAT on switches.

Networks and IPs are not real one.
Lats say that we have public following networks:
<DMZ> Network advertised over BGP: 1.2.0.0/22
<RUT2FW> (Cisco to OPNsense): 10.1.0.0/24
<LAN>: 10.1.1.0/24
<REM>Remote network on IPsec: 10.2.1.0/24

Configuration is like this: Datacenter Net <-> Cisco SW <RUT2FW> OPNsense <LAN>
                                                                          <DMZ>
<RUT2FW> SW1: 10.1.0.2
<RUT2FW> SW2: 10.1.0.3
<RUT2FW> SW HSRP: 10.1.0.1
<RUT2FW> RUT1: 10.1.0.11
<RUT2FW> RUT2: 10.1.0.12
<RUT2FW> RUT CARP: 10.1.0.10
<LAN>RUT1: 10.1.1.2
<LAN>RUT2: 10.1.1.3
<LAN>RUTCARP: 10.1.1.1
<DMZ>RUT1: 1.2.0.2
<DMZ>RUT2: 1.2.0.3
<DMZ>RUTCARP: 1.2.0.1

On switches we have following routes:
ip route 1.2.0.0 255.255.252.0   10.1.0.10
ip route 1.2.0.2 255.255.255.255 10.1.0.11
ip route 1.2.0.3 255.255.255.255 10.1.0.12

We have configured HA as described in documentation: https://docs.opnsense.org/manual/how-tos/carp.html
And default gateway on both OPNsense boxes is 10.1.0.1 (WAN_GW).

But after that we have some real problems.
1. <LAN> to <REM> traffic was flowing to WAN instead through IPsec tunnel.
2. Firmware update timed out.
3. Unbound was not working.

How we resolved first problem:
1. We are running IPsec on DMZ_CARP interface, because WAN is private network without NAT.
2. OPNsense route traffic directly to WAN_GW with Outbound NAT applied to it, before hitting IPsec.
3. Add rule in firewall -> Outbound NAT
   Interface: RUT2FW
   Source: 10.1.1.0/24
   Destination: 10.2.0.0/24
   Do not NAT: checked
   Network traffic
4. Now IPsec traffic flows as expected.

Resolution of second problem:
1. OPNsense itself want to reach internet with its WAN IP.
2. Ok, we add Outbound rule:
   Interface, Source, NAT to
   RUT2FW, 10.1.0.0/24, DMZ CARP address
3. This works on currently active Master, but not on slave. Logicaly.
4. But we change DMZ CARP addres in that rule to DMZ address, and same story.
   After checking slave OPNsense their Outbound rules shows that its NAT to address is actualy DMZ address of master.
   Because of that traffic coming out from slave returns to master.
4. Our solution is that instead of one rule in point 2 we add following rules. Adding rule with no XMLRPC Sync is not possible, because if we add rule on Slave OPNsense it will be overwritten with config Sync from Master. And we also want to avoid double configuration by hand on muster and slave because of bigger possibility of mistakes.
   Interface, Source, NAT to
   RUT2FW, 10.1.0.1, 1.2.0.1
   RUT2FW, 10.1.0.2, 1.2.0.2
   RUT2FW, 10.1.0.3, 1.2.0.3
5. After that change both OPNsense boxes can reach internet, and services like unbound are working normaly.

Yes it will be much easier to take slice of our network for Cisco to OPNsense connection but we did not want to throw away public address space.
I hope that also part of this can find way in documentation for someone else in such not everyday setup.




But there is still some problems that we can not solve and I hope that someone will be able to answer it.

Our actual DMZ interface setup is like this:
RUT1: 1.2.0.2/24, RUT2: 1.2.0.3/24
CARP VHID5: 1.2.0.1/24, CARP VHID5: 1.2.1.1/24, CARP VHID5: 1.2.2.1/24, CARP VHID5: 1.2.3.1/24

One of them is that in IPsec tunnel setting for interface we can not chose CARP all of this CARP IPs.
Actually we can chose only one CARP IP, only first IP that was entered within the same VHID.
Is this normal behavior ?

We are currently running version 19.1.4 and tonight we will update and reboot system and I can see if there will be any difference.

And another one is installation of OPNsense. I installed it yesterday in VM several times and always cut me off web interface after wizard. (also 19.1.4 DVD).
I figured out that I can login in Web interface after installation with my root password but after not putting anything for root password in web wizard it change it to default password.

Also I had some problems with DHCP static leases.
After adding static lease on master node I must restart DHCP service on master and slave otherwise computer get IP from DHCP range.
Can someone else verify this ?


Best regards, Robi