Topics

I have the following constellation:
Local Servers-----OPNSense-----WAN-----Sophos----Remote Servers
OPNSense and Sophos have a S2S IPSec VPN

Local Subnet 10.99.201.0/24
Remote Subnet 10.99.11.0/24

This works fine, but I want to be able to access the Remote Servers (I have one Domain COntroller local and two remote) with the OPNsense.
Obviously this does not work out of the box, because packets from the Sense itself are routed out the WAN, whose IP is not allowed in the S2S tunnel.

So I added the following Outbound NAT Rule on the top:
Interface   Source   Source Port   Destination   Destination Port   NAT Address   NAT Port   Static Port   Description   
      WAN   This Firewall   *   Remote Subnet     *   10.99.201.1   *   NO   

afaik this should masquerade the requests coming from the OPNsense with its IP in the Local Subnet which is allowed in the Tunnel.
Unfortunately this does not work.

Can someone explain to me how I get this to work?

I have a workaround for Unbound, which is to select the Local Subnet as Outgoing Interface which allows the OPNsense to use the Remote DCs for DNS queries. But this workaround does not work for authentication, as it is not possible to select an outgoing interface for LDAP servers. Which means I have no redundancy for authentication when the local DC is not available.

Can anybody enlighten me if a.) this should work or b.) show me another workaround to use the remote DCs for LDAP over S2S

I have the following configuration:
OPNSense A-----|
                        |-------DSL Router
OPNSense B-----|

The OPNSense have a VIP 10.99.224.10 and the DSL router has 10.99.224.1

I set up the following Shaper configuration:



When looking at the status I can see that the rules match no traffic to the Schedulers:

Code Select Expand

Limiters:
10000:  35.000 Mbit/s    0 ms burst 0
q75536  50 sl. 0 flows (1 buckets) sched 10000 weight 0 lmax 0 pri 0 droptail
sched 75536 type FIFO flags 0x0 0 buckets 1 active
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  0 ip           0.0.0.0/0             0.0.0.0/0     12498 18565328 32 46555 274
10001:   9.000 Mbit/s    0 ms burst 0
q75537  50 sl. 0 flows (1 buckets) sched 10001 weight 0 lmax 0 pri 0 droptail
sched 75537 type FIFO flags 0x0 0 buckets 1 active
  0 ip           0.0.0.0/0             0.0.0.0/0       68     2871  0    0   0


Schedulers:
10000:  35.000 Mbit/s    0 ms burst 0
q75536  50 sl. 0 flows (1 buckets) sched 10000 weight 0 lmax 0 pri 0 droptail
sched 10000 type FQ_CODEL flags 0x0 0 buckets 0 active
FQ_CODEL target 5ms interval 100ms quantum 300 limit 1000 flows 1024 ECN
10001:   9.000 Mbit/s    0 ms burst 0
q75537  50 sl. 0 flows (1 buckets) sched 10001 weight 0 lmax 0 pri 0 droptail
sched 10001 type FQ_CODEL flags 0x0 0 buckets 0 active
FQ_CODEL target 5ms interval 100ms quantum 300 limit 600 flows 1024 NoECN

The rules are set like this (direction in respectively for down):


As I am doing NAT masquerading to 10.99.224.10 for everything I treid setting the rules to match both direction and instead set source (respectively destination for the other direction) to the VIP 10.99.224.10 but then neither Limiter nor Scheduler showed any traffic, which I understand as that my rules are correct but they are not matching correctly for Schedulers.

I have two OPNsense behind each other.
The outer OPNsense A has a fixed /56 Subnet.
The inner OPNsense should get a /60 via PD.

But B got a /62 before I manually set up the DHCPv6 Server on A
So now B has a /62 PD from A.
I setup A to give out a /60 PD range from ::10 to ::20
Also I set up B to request a /60 from A via PD (Prefix delegation size 60, send prefix hint yes)

How can I release the /62 from either B or delete the lease on A?
I already change the DUID on B but it keeps getting an /62 and there is no possibility of deleting the leases in DHCPv6 Server

The DHCPv6 lease Table on A looks like this
IPv6 Prefix   IAID   DUID   Start   End   State
2a01:dead:beef:1c42::2000 2a01:dead:beef:1cf0::/62   1   00:03:00:01:b8:be:de:ad:be:ef   2019/08/05 20:56:19   2019/08/05 22:56:19   active

Also B does not use this PD for the LAN interface which is tracking the upstream interface.

Our client PCs have connection problems when in a CARP cluster the Backup node is restarted.
I think the problem is related to https://github.com/opnsense/core/issues/3197 and this issue has not been fully understood and resolved.

I can see following in the log of the Master when restarting the Backup:
Mar 25 08:23:57   opnsense: /usr/local/etc/rc.newwanip: On (IP address: 172.16.0.2) (interface: PFSYNC[opt5]) (real interface: igb5).
Mar 25 08:23:57   opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb5'
Mar 25 08:23:57   opnsense: /usr/local/etc/rc.linkup: Hotplug event detected for PFSYNC(opt5) but ignoring since interface is configured with static IP (172.16.0.2 ::)
Mar 25 08:23:57   kernel: igb5: link state changed to UP
Mar 25 08:23:53   opnsense: /usr/local/etc/rc.linkup: Hotplug event detected for PFSYNC(opt5) but ignoring since interface is configured with static IP (172.16.0.2 ::)
Mar 25 08:23:53   kernel: igb5: link state changed to DOWN
Mar 25 08:22:04   opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface PFSYNC.
Mar 25 08:22:03   opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Mar 25 08:22:03   opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv4 default route
Mar 25 08:22:03   opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv6 default gateway set, assuming wan
Mar 25 08:22:03   opnsense: /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan
Mar 25 08:22:03   opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'opt5'
Mar 25 08:22:03   opnsense: /usr/local/etc/rc.newwanip: On (IP address: 172.16.0.2) (interface: PFSYNC[opt5]) (real interface: igb5).
Mar 25 08:22:03   opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb5'
Mar 25 08:22:03   opnsense: /usr/local/etc/rc.linkup: Hotplug event detected for PFSYNC(opt5) but ignoring since interface is configured with static IP (172.16.0.2 ::)
Mar 25 08:22:03   kernel: igb5: link state changed to UP
Mar 25 08:21:59   opnsense: /usr/local/etc/rc.linkup: Hotplug event detected for PFSYNC(opt5) but ignoring since interface is configured with static IP (172.16.0.2 ::)
Mar 25 08:21:59   kernel: igb5: link state changed to DOWN

So the dedicated PFSYNC interface is going down and up again as expected, but it is also calling rc.newwanip which causes connection problems on client PCs.

Does anyone have the same problem in this configuration?
(VIP on LAN and WAN + dedicated direct PFSYNC connection)

Hi,

I'm trying to use tags in rules but I think I am missing some knowledge.
What I try to achieve:
All packets exiting through the wan interface should be allowed when they are coming from a specific network.
How I try to achieve this:
I tag packets on the manual outbound masquerading NAT rule.
I then match this tag on a floating rule on the WAN interface for outbound packets.

Example:
Outbound NAT on WAN for source 192.168.1.0/24, target any, translate source to WAN IP, add tag "internet"
Floating Rule pass on WAN for source any, target any, direction out, match tag "internet"

Processing order afaik is:

• Outbound NAT rules

: tag "internet"

• Inbound NAT rules such as Port Forwards
• Internal automatic rules (pass and block for various items)
• Rules defined on the floating tab

: match "internet" and pass

• Rules defined on interface group tabs (Including IPsec and OpenVPN)
• Rules defined on interface tabs (WAN, LAN, OPTx, etc)
• Automatic VPN rules

But the packets coming from 192.168.1.0/24 going to WAN still are dropped by the default drop rule on interface LAN. Floating rule is "quick".

Does anyone have an idea what I am doing wrong?

Since we are on 19.1.1 our WAN connection renews exactly every 20 min.
We noticed it because random states were dropped from the state table.
IPSec was sending packets but incoming packets for the same connection were dropped by default drop etc.

I found following System Log entries:

Code Select Expand

Feb 11 12:59:33 opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface RB99_WAN.
Feb 11 12:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Feb 11 12:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway '185.160.245.1'
Feb 11 12:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 185.160.245.1
Feb 11 12:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv6 default gateway set, assuming wan
Feb 11 12:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv4 default gateway set, assuming wan
Feb 11 12:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
Feb 11 12:59:26 opnsense: /usr/local/etc/rc.newwanip: On (IP address: x.x.x.x) (interface: RB99_WAN[wan]) (real interface: igb0).
Feb 11 12:59:26 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb0'
Feb 11 12:39:33 opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface RB99_WAN.
Feb 11 12:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Feb 11 12:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway '185.160.245.1'
Feb 11 12:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 185.160.245.1
Feb 11 12:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv6 default gateway set, assuming wan
Feb 11 12:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv4 default gateway set, assuming wan
Feb 11 12:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
Feb 11 12:39:26 opnsense: /usr/local/etc/rc.newwanip: On (IP address: x.x.x.x) (interface: RB99_WAN[wan]) (real interface: igb0).
Feb 11 12:39:26 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb0'
Feb 11 12:21:39 opnsense: /index.php: User logged out for user 'root' from: 192.168.220.167
Feb 11 12:20:52 opnsense: /diag_ipsec_spd.php: Successful login for user 'adm_frr' from: 192.168.220.160
Feb 11 12:19:33 opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface RB99_WAN.
Feb 11 12:19:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Feb 11 12:19:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway '185.160.245.1'
Feb 11 12:19:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 185.160.245.1
Feb 11 12:19:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv6 default gateway set, assuming wan
Feb 11 12:19:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv4 default gateway set, assuming wan
Feb 11 12:19:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
Feb 11 12:19:27 opnsense: /usr/local/etc/rc.newwanip: On (IP address: x.x.x.x) (interface: RB99_WAN[wan]) (real interface: igb0).
Feb 11 12:19:27 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb0'
Feb 11 11:59:32 opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface RB99_WAN.
Feb 11 11:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Feb 11 11:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway '185.160.245.1'
Feb 11 11:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 185.160.245.1
Feb 11 11:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv6 default gateway set, assuming wan
Feb 11 11:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv4 default gateway set, assuming wan
Feb 11 11:59:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
Feb 11 11:59:26 opnsense: /usr/local/etc/rc.newwanip: On (IP address: x.x.x.x) (interface: RB99_WAN[wan]) (real interface: igb0).
Feb 11 11:59:26 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb0'
Feb 11 11:39:33 opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface RB99_WAN.
Feb 11 11:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Feb 11 11:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway '185.160.245.1'
Feb 11 11:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 185.160.245.1
Feb 11 11:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv6 default gateway set, assuming wan
Feb 11 11:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv4 default gateway set, assuming wan
Feb 11 11:39:27 opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
Feb 11 11:39:27 opnsense: /usr/local/etc/rc.newwanip: On (IP address: x.x.x.x) (interface: RB99_WAN[wan]) (real interface: igb0).
Feb 11 11:39:27 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb0'

The IP address does not change when this happens.
This did not happen with 18.7.10_4.
Hardware is an APU3C4 with Bios 4.0.23

Any idea what is causing these unnecessary renewals which happen exactly all 1200s?

Using OPNSense 18.7.
Under "Services -> Intrusion Detection -> Administration -> Downloads" on the bottom there is this text: "Please use "Download & Update Rules" to fetch your initial ruleset, automatic updating can be scheduled after the first download."
Where can these automatic updates be scheduled?
There is no "Schedule" tab anymore like in earlier versions of OPNSense

I have the following config:

Firewall A:
- Local Interface "LAN" 10.1.0.1/24

- 2 IPSEC Tunnels A+B

- Phase 1 to Firewall B: irrelevant
- Phase 2 to Firewall B
   - Tunnel A is 10.1.0.0/24 local to 10.2.0.0/24 remote

- Phase 1 to Firewall C: irrelevant
- Phase 2 to Firewall C
  - Tunnel B is 10.3.0.0/24 local to 10.4.0.0/24 remote
  - Tunnel B also has Manual SPD Entries: 10.1.0.0/24

Firewall C:
- Phase 1 to Firewall A: irrelevant
- Phase 2 to Firewall A:
  - Tunnel B is 10.4.0.0/24 local to 10.4.0.0/24 remote


We now have a BiNAT setup for:
Interface: IPSEC
Type: BiNAT
External Net: 10.3.0.0/24
Source: 10.1.0.0/24
Destination: 10.4.0.0/24

We no send a packet from 10.1.0.100 to 10.4.0.1.100
We see the packet arrive on "LAN" in a packet dump
We do NOT see the packet on the "IPSEC" interface

As a 2nd test we send a packet from 10.1.0.100 to 10.2.0.100, we can see it on "LAN" and also on the "IPSEC" interface.

I conclude that our Packet gets lost between LAN and IPSEC interfaces on our OPNSense.
Can anyone give me a hint on how to troubleshoot this issue?

Edit:
- clarified configuration

Hi There,

How can we get postfix to work with Virtual IPs?
We have added the VIP as "Listening IP" in the postfix config.
Postfix is receiving mail on this IP but when sending it takes the real interface IP nonetheless.
We use OpnSense 18.1.7_1.

Best Regards

Hallo!

Wir haben einen Cluster aus 2 APU3C4 gebaut.
Wir setzen OPNSense 18.1.5 ein.
Darauf sind 4 CARP Virtual IPs auf VLANs auf einem Interface (igb1).
Mittels CARP Maintenance Mode können wir die VIPs beliebig hin und her schieben, was hervorragend funktioniert.
Weiterhin sehen wir jeweils die CARP Pakete auf beiden Firewalls (mit tcpdump).
Wenn wir igb1 auf dem Master trennen (Stecker ziehen) geht der Master Status auf allen 4 Interfaces schön auf die andere Firewall über.
Sobald igb1 wieder verbunden wird wird es lustig.
Der CARP Status verschwindet auf zufälligen Interfaces und wird auf Firewall A oder B Master.
z.B.
Vor Failover:
WAN: Master WAN: Backup
LAN: Master LAN: Backup
OPT1: Master OPT1: Backup
OPT2: Master OPT2: Backup

Bei Failover:
WAN: Init WAN: Master
LAN: Init LAN: Master
OPT1: Init OPT1: Master
OPT2: Init OPT2: Master

Nach Failover z.B.:
WAN: Master WAN: Backup
LAN: (Keine Angabe!) LAN: Master
OPT1: Master OPT1: Backup
OPT2: (Keine Angabe!) OPT2: Master

Die CARP Konfig scheint auf betroffenen Interfaces komplett zu verschwinden, dadurch bleibt die IP natürlich auf der 2. Firewall da sie der einzige Teilnehmer des CARP ist. Erst ein Reboot beider Firewalls scheint zu helfen.

Hat jemand einen Lösungsvorschlag oder eine Idee weshalb die Konfig verloren geht?