Messages

1

23.1 Legacy Series / Re: Upgrade to 23.1.5 - No wireguard traffic (empty alias problem?)

« on: March 29, 2023, 08:09:08 pm »

for me it is not related to ntpd.

it is the same behaivor again as descripted here:
https://github.com/opnsense/core/issues/5788

- Create an alias with only one network in it
- reboot
- pfctl -t $ALIAS_NAME -T show - returns nothing

2

23.1 Legacy Series / Re: Upgrade to 23.1.5 - No wireguard traffic

« on: March 29, 2023, 04:16:47 pm »

root@MGMT-FW02:~ # configctl template reload OPNsense/Filter
OK

... but alias still empty

3

23.1 Legacy Series / Re: Upgrade to 23.1.5 - No wireguard traffic

« on: March 29, 2023, 03:51:17 pm »

Hi franco,

Applying aliases doesn't fix the issue.
i did run "/usr/local/opnsense/scripts/filter/update_tables.py" which returned {"status": "ok"} - but alias is still empty
here are some screenshots:

Alias defined as:


not showing up under Firewall -> Diagnostics -> Aliases:


Thanks,
BR

Edit: Strange thing is that other aliases with networks working well, also wenn i create a Internal_LAN2 with the same Subnet it is working perfectly...

4

23.1 Legacy Series / Re: Upgrade to 23.1.5 - No wireguard traffic

« on: March 29, 2023, 03:39:00 pm »

and if you look at Firewall -> Diagnostics -> Aliases... are your aliases empty as well?

5

23.1 Legacy Series / Re: Upgrade to 23.1.5 - No wireguard traffic

« on: March 29, 2023, 03:23:13 pm »

Are you using network-Aliases in the corresponding Firewall-Rule?

For me 23.1.5 seems to have issues with network-aliases again.

When i look at Firewall -> Diagnostics -> Aliases some of me network-aliases are empty. (maybe something like this issue? https://github.com/opnsense/core/issues/5788)

6

22.1 Legacy Series / Re: Alias based firewall rules doesn't work after upgrade to 22.1.8

« on: May 25, 2022, 10:20:01 pm »

Have you reported this as a bug on GitHub? If not please do - sounds like a bug and that will get resolved earlier if a GitHub report is made.

issue on github already reported:
https://github.com/opnsense/core/issues/5788

7

22.1 Legacy Series / Re: Alias based firewall rules doesn't work after upgrade to 22.1.8

« on: May 25, 2022, 09:03:58 pm »

Seems to be some kind of bug.
Under Firewall->Diagnostics->Aliases some aliases doesn't show results(see attached screenshots)

8

22.1 Legacy Series / Re: Alias based firewall rules doesn't work after upgrade to 22.1.8

« on: May 25, 2022, 03:37:45 pm »

I've seen a similar behaivor. After upgrading to 22.1.8 some rules stopped working...
Had no time to troubleshoot this further and revented back to 22.1.7.

Will try to reproduce it later and report here.

9

20.7 Legacy Series / SMB copy breaks IPSec

« on: November 14, 2020, 10:14:05 pm »

Hey Guys,

I want to report some strange behavior which I've seen on different OPNSense-Boxes in the past weeks/month:

Sometimes IPSec-tunnels just simply get stuck somehow....
"stuck" means: tunnel is still established but no packets flow through the IPSec-interface. I still see ESP-packets on the WAN-interface of the partner-box, but nothing is visible in the IPSec-interface. Absolutley nothing in the IPSec-Log.

Currently I'm troubleshooting an IPSec-tunnel between two OPNSense-boxes(both 20.7.4, one physical one virtual):
Tunnel goes up normally without any errormessages in the logs.
Now the strangest thing in this issue: As soon as i start to copy a file(approx. 100MB) from SiteA to SiteB via SMB the tunnel get "stuck". The only solution is to restart the tunnel.

Some other services like RPC aren't working as well without setting MSS to something lower then 1360.

I tried everything came to my mind:
- changed tunnel from policy-based to route-based
- changed MTU/MSS on all involved interfaces - higher<->lower, doesn't make any difference
- tried to fix via normalization-rules
- changed from IKEv1 to v2, completley recreated the tunnels
- setup a completley new virtual opnsense
- ....

I'm out of ideas at the moment...

it must be related to packet-sizes/fragmentation, but i can't find a solution... and i absolutly have no explaination for a tunnel breaking down due to SMB-copy....
at the moment it is working fine with an OpenVPN-S2S-Tunnel, but i really want to find a fix for this IPSec-issues.

I'm working with OPNSense about 3 years now, managing dozends of boxes with dozends of tunnels. There were problems with IPSec since the beginning of my OPNSense-journey (mostly packet-size related). Some tunnels just work, others don't do. I couldn't figure out the differences. Many times it was just fixed by lowering the MTU to 1450. (especially with PPPoE involved - anyone can explain why?)

Last week I had a similar-problem with a few tunnels on anther 20.7.4 box. Everytime i restarted the IPSec-service 1-3 ICMP-Pings got trough the tunnel. Then "stuck" as described  above.
Could be the same root-cause, but i didn't troubleshooting that in deep, as i fixed this via a second opnsense, which manages the IPSec-Tunnels now.

Over the last month, especially since 20.1, I think the MTU-problems over IPSec are more freqently.

If anyone has an idea how to troubleshoot this further, please share your thoughts/experieneces.

Thanks in advance!

10

20.7 Legacy Series / Re: Strange routing behaivor

« on: August 26, 2020, 09:43:14 am »

problem was caused by vmware promiscuous mode 

it is solved now

11

20.7 Legacy Series / Re: Strange routing behaivor

« on: August 06, 2020, 05:39:16 pm »

my idea is now that it has something to do with vmware promiscuous mode...

but why did the behaivor change from 20.1.9 to 20.7(nothing was changed on the VMWare-side)?

12

20.7 Legacy Series / Strange routing behaivor

« on: August 04, 2020, 02:30:56 pm »

Hey Guys,

I've discovered a strange routing-behaivor since the upgrade to 20.7.
To illustrate i've drawn this nice schema  Its kind of complex setup... hopefully I can clarify.



Some OPNSense-Firewalls(running in VMWare, vNICs in differnt VMNetworks(VLANs)) are connected to a transport-net which is used for routing between LANs. Every OPNSense does have its own LAN-network(differnt VLANs as well). Not every firewall knows each LAN-Route.


Routing-tables look like this(static):

OPNSense1:
default via internet-gw
LAN2 via transport.2
LANn via transport.n
and so on....

OPNSense2:
default via internet-gw
LANn via transport.n
and so on....

since the upgrade to 20.7 I've seen excessive traffic (20-40MBit where there was less then 1MBit pre 20.7) on some of these firewalls that doesn't even belong to the firewall. Packets should not get there as there is no route defined.
wrong(misdirected) traffic does appear on the WAN-interface as well as the transport-interface.

traceroute (wrong - public IPs shouldn't appear here)

Code: [Select]

  1    <1 ms    <1 ms    <1 ms  fw01 [LAN1.1]
  2    <1 ms    <1 ms    <1 ms  transport.9
  3    <1 ms     2 ms    <1 ms  internet.87
  4    <1 ms    <1 ms    <1 ms  internet.19
  5     2 ms     3 ms     3 ms  internet.87
  6    <1 ms    <1 ms    <1 ms  internet.87
  7    <1 ms    <1 ms    <1 ms  internet.87
  8    <1 ms     1 ms     1 ms  internet.19
  9     2 ms    <1 ms     1 ms  internet.19
 10     1 ms     1 ms     1 ms  internet.87
 11     1 ms     3 ms     3 ms  internet.87
 12     1 ms     1 ms     1 ms  internet.19
 13     1 ms     1 ms     1 ms  internet.87
 14     1 ms     2 ms     1 ms  LANn.2

traceroute should look like

Code: [Select]

traceroute:
  1    <1 ms    <1 ms    <1 ms  fw01 [LAN1.1]
  2    <1 ms    <1 ms    <1 ms  transport.28
  3     1 ms     2 ms     1 ms  LANn.2

traceroutes aren't even consistent, changing every time I test...

tcpdump

Code: [Select]

14:03:44.525830 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.525871 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.525900 IP transport.23 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.525927 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526040 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526096 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526206 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526222 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526237 IP transport.23 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526254 IP transport.23 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526264 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526280 IP transport.100 > LANn.2: ICMP time exceeded in-transit, length 100
14:03:44.526342 IP transport.9 > LANn.2: ICMP time exceeded in-transit, length 100

and it is not only ICMP, every protocol appears in tcpdump on wrong firewalls(TCP,UDP,ESP,...)


funny thing about the scenario: everything is working fine currently except the higher bandwith 

I'm out of ideas here...
was there a basic routing-change in FreeBSD 12.1 somehow?!

Anyone does have a clue how to troubleshoot this?

thanks in advance!