Menu

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.

Show posts Menu

Messages - loganx1121

#1
I've been monkeying around with monit trying to figure out how to do this but haven't had any luck yet.  I basically just want it to send an email anytime the configuration on the firewall has been changed, i.e a new rule is added, a rule is disabled/enabled, etc.

Does anyone know if this is possible?
#2
Quote from: mimugmail on January 18, 2023, 06:16:44 AM
Is there a second Cluster un this network?

Just 2 firewalls in a single HA pair.  I actually resolved this by disabling pre-emption on the secondary. 
#3
Quote from: FraLem on January 18, 2023, 06:37:20 AM
Quite useful as well for 1:1 NAT
Rgds

I guess I'm not understanding.  Why would this be useful for 1:1 NAT?  Wouldn't the NAT by itself function?
#4
So I'm kind of wondering what the IP Alias virtual IP is actually used for in a real world scenario and I'm wondering if it's for what I'm trying to do.

I have a Public IP space from my ISP, let's call it 192.168.1.1/27 for the sake of argument. Within that space, I have port forwarding setup and I've made firewall alias's to assign servers to Public IP's within that space. My connection with the ISP is a direct connection, meaning I'm not routing over some interim network to get to them, I just point at the gateway they gave me.

So if my primary firewall goes down, or I fail it over manually, will those port forwards still "just work", or is this where I would define the public IP of these servers as an "IP Alias" in the virtual IP's?
#5
If I manually change the skew of the virtual IP on the primary to something above 100 (which is what the secondary is set to) then the primary becomes the backup.  I also found this github post that seems relevant but it looks like this was already patched back in 2019. https://github.com/opnsense/core/issues/3671

I recreated the same topology in GNS3 and I'm seeing the same issue there.  GNS3 is using version 22.1.2_2 and my "real" version is 22.10
#6
I find it interesting that I don't see any new traffic on either firewall when I enter maintenance mode on the primary. 
#7
I deleted all of the virtual IP's and configured just 1 for a single VLAN.  Here is a packet capture from that VLAN interface on the secondary firewall.  After I started the capture I tried to enable maintenance mode on the primary


VLAN_10_Active_Directory
vlan01 09:31:25.810669 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0xe0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 56)
    10.110.10.2 > 224.0.0.18: vrrp 10.110.10.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 160.210.4.23,235.105.4.180,113.194.71.99,176.7.125.190,245.170.7.212,120.225.232.142,10.65.27.171
    10.110.10.2 > 224.0.0.18: vrrp 10.110.10.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 13.99.217.19,131.170.210.220,10.55.161.162,117.164.121.126,229.17.234.117,101.70.133.79,12.136.252.26
    10.110.10.2 > 224.0.0.18: vrrp 10.110.10.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 240, authtype none, intvl 1s, length 36, addrs(7): 158.236.0.177,106.209.71.251,204.211.6.131,53.175.7.127,178.250.195.244,6.252.140.171,36.40.171.150
    10.110.10.2 > 224.0.0.18: vrrp 10.110.10.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 240, authtype none, intvl 1s, length 36, addrs(7): 227.229.191.192,21.166.15.213,19.133.21.216,251.37.38.71,65.1.102.92,83.36.20.109,142.201.180.76
    10.110.10.2 > 224.0.0.18: vrrp 10.110.10.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 240, authtype none, intvl 1s, length 36, addrs(7): 59.210.190.198,13.88.70.116,219.49.97.178,37.201.88.145,70.7.92.84,238.130.171.236,243.47.41.238
    10.110.10.2 > 224.0.0.18: vrrp 10.110.10.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 108.180.155.137,155.144.229.212,9.124.122.114,79.49.195.250,125.226.65.230,24.228.173.183,26.75.230.227
    10.110.10.2 > 224.0.0.18: vrrp 10.110.10.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 137.44.149.172,67.170.162.10,248.22.34.249,125.82.231.76,60.179.78.110,235.132.159.181,71.132.92.170
    10.110.10.2 > 224.0.0.18: vrrp 10.110.10.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36, addrs(7): 254.102.126.151,229.62.112.146,227.23.161.59,120.249.23.183,196.151.35.87,50.189.145.49,60.92.216.168
VLAN_10_Active_Directory
vlan01 09:31:26.873849 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0xe0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 56)
VLAN_10_Active_Directory
vlan01 09:31:26.938052 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0xe0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 56)
VLAN_10_Active_Directory
vlan01 09:31:28.892743 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0xe0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 56)
VLAN_10_Active_Directory
vlan01 09:31:30.926398 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0xe0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 56)
VLAN_10_Active_Directory
vlan01 09:31:32.049355 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0xe0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 56)
VLAN_10_Active_Directory
vlan01 09:31:33.064451 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0xe0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 56)
VLAN_10_Active_Directory
vlan01 09:31:34.124511 00:00:5e:00:01:01 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: (tos 0xe0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 56)
#8
Quote from: pmhausen on January 17, 2023, 06:17:25 PM
"maintenance"

Ah.  Unfortunately I only have the one switch to use.  Well, it's 2 in a stack.  I did globally disable igmp snooping though, which according to cisco documentation here:

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/68131-cat-multicast-prob.html

If you disable IGMP snooping, all switches treat multicast traffic as a broadcast traffic. This floods the traffic to all the ports in that VLAN, regardless of whether the ports have interested receivers for that multicast stream.

So by disabling, it should get where it needs to go, but the behavior is still the same.
#9
Quote from: mimugmail on January 17, 2023, 05:58:09 PM
You should test with a different switch. If you enable mnt and its still Master, node 2 doesnt get the packets or are filtered

Sorry?  Enable mnt?
#10
2 Opnsense firewalls with VIPs configured for the WAN interfaces and the backend VLANS. All VLANs live on the firewall and I'm trunking over a LAGG from a cisco switch. I can't seem to get CARP maintenance mode to do anything. I see the CARP demotion level increase to 240, but the primary firewall still shows as the master.

I was checking the traffic logs and I saw the IGMP traffic from the VLAN interface being blocked, so I made a rule to allow that but that didn't seem to help. I also globally disabled IGMP snooping on the cisco switch, but that had no effect either.

Just wondering if anyone else has run into this. If I disable CARP it seems to failover fine, and I've already tried recreating all the virtual IP's.  I also confirmed I can ping from the VLAN interface of 1 firewall to the same VLAN on the other firewall, so it doesn't seem to be a connectivity problem. 
#11
Quote from: pmhausen on December 31, 2022, 03:42:52 PM
For MSCHAP to work, RADIUS needs access to a clear text or NT hashed password. You cannot perform MSCHAP when authenticating with another remote entity over e.g. LDAP. It should possible to place the RADIUS server on the domain controller in form of MS IAS (Internet Authentication Server - essentially RADIUS included in Windows Server).

Other than that I am a bit out of that area of expertise for quite some years now, sorry. Your best bet is probably the freeradius-users mailing list.

What about XAUTH with plain user/password with LDAP backend and a certificate managed by your Windows CA for each user?

Well it's around 500 users, so doing a certificate for each of them would be a lot of overhead that I'm trying to avoid.

So you're saying mschap won't work because the FreeRADIUS plugin can't do mschap with the domain controller?  I'm a little confused on that part.
#12
22.7 Legacy Series / FreeRADIUS and IPsec Mobile client
December 31, 2022, 01:46:46 PM
Link to same post on reddit for screenshot purposes since attachments here are limited - https://www.reddit.com/r/OPNsenseFirewall/comments/zzt3mq/freeradius_and_ipsec_mobile_client/


I'm trying to use the FreeRADIUS plugin for an IPsec mobile client. Previously had the mobile client working with local accounts, but I need to do this for 400+ people so I figured why not use RADIUS?

So I have the FreeRADIUS plugin installed, which points to a windows domain controller that is sitting behind another firewall at another location. The 2 firewalls have a wireguard tunnel.

FreeRADIUS has LDAP enabled, just boring port 389 to test this out, and a client setup of 127.0.0.1. The RADIUS server in system > access > servers is also set as 127.0.0.1. When I use the tester, I see the port 389 traffic go across to the WG tunnel, and the tester shows the auth is successful.

However, when I try to do this with windows built-in VPN and connect to the IPsec mobile client on the same firewall that FreeRADIUS is running on, I get the following:


2022-12-30T23:33:11 Auth: (19) Login incorrect (eap_peap: The users session was previously rejected: returning reject (again.)): [mo/<via Auth-Type = eap>] (from client test port 7 cli x.x.x.x[4500])

2022-12-30T23:33:11 Auth: (18) Login incorrect (mschap: FAILED: No NT-Password. Cannot perform authentication): [mo/<via Auth-Type = eap>] (from client test port 0 via TLS tunnel)

2022-12-30T23:31:26 Auth: (9) Login incorrect (eap_peap: The users session was previously rejected: returning reject (again.)): [mo/<via Auth-Type = eap>] (from client test port 6 cli x.x.x.x[4500])

2022-12-30T23:31:26 Auth: (8) Login incorrect (mschap: FAILED: No NT-Password. Cannot perform authentication): [mo/<via Auth-Type = eap>] (from client test port 0 via TLS tunnel)


The firewall has a root CA made on OPNsense, and from that I issued 2 server certificates - 1 for the IPsec tunnel and 1 for FreeRADIUS. I read somewhere that the IPsec cert and the FreeRADIUS cert had to be the same cert to make this work, so I tried using the IPsec cert in both places but that didn't seem to help.

The client (virtual machine) that is trying to connect has the root CA installed in the "Trusted certificate authorities" in the computer certificates (not personal certificates). I did this when I was using local accounts on the firewall to connect to the IPsec mobile client connection and had it working.

I'm kind of at a loss. The tester says auth works. I see the traffic go over the tunnel. I can only assume return traffic isn't an issue since if it was I would think using the "Tester" wouldn't work either. The common name on both the IPsec cert and the RADIUS cert is the public DNS entry of the firewall.

I've tried PEAP, mschapv2, EAP-TTLS, but can't get any of those to work.  I'm hoping this is just something dumb I missed that someone can point out to me.
#13
22.7 Legacy Series / SFP's not detected on dell appliance
December 06, 2022, 11:04:06 PM
We have some new dell appliances with 2 SFP cards, 4 SFP+ ports total (2 per card). 10 interfaces total, with the other 6 being 1Gig RJ45.

All the RJ45 interfaces are being detected by OPNsense, but the SFP ports are not. Does anyone have any ideas as to why this would be? I confirmed the hardware shows in the IDRAC on the appliance.

I did read something about having to add sfxge_load="YES" to the /boot/loader.conf file, but that was for pfsense and I'm not sure if that applies here.

All the interfaces are broadcom. The SFP's specifically are: Broadcom 57412 Dual Port 10GbE SFP+ Adapter, PCIe Low Profile [540-BBVI] / 5100635

Thanks in advance.
#14
Yeah I had tried that already.  The interfaces are set to the management interface, and the port forward rule is showing on a different interface...I'll put in some screenshots
#15
I made a new VLAN for my LAGG and somehow, the anti-lockout rule under portforwarding is now on this interface.  This is just a sandbox VLAN for me to test things, so I definitely don't want it on there.  I know I can disable the anti-lockout rule all together but is there a way to move the interface for this?