Messages

1

24.1 Legacy Series / Re: NAT outbound port translation

« on: July 09, 2024, 05:46:11 pm »

Yes. I can successfully add an outbound rule to translate to port 53, when I change the inbound (port forwarding) rule to another port. But that is not acceptable for the DNS protocol:

nslookup -port=54 example.com PUBLIC_IP
;; reply from unexpected source: PUBLIC_IP#53, expected PUBLIC_IP#54

2

24.1 Legacy Series / NAT outbound port translation

« on: July 09, 2024, 04:34:40 pm »

Hello,

I'm running an authoritative DNS server behind an opnsense firewall. I've created a port forwarding for port 53 to my primary DNS server and added the necessary firewall rules. That part works. When using the DNS protocol, the clients expects to receive the response from the public IP and the port 53 otherwise the request fails:

Unexpected source: $PUBLIC_IP#54, expected $PUBLIC_IP#53

Therefore I created an outbound NAT rule:

Interface: WAN
Protocol: UDP
Source: Internal_IP of DNS server
Source port: 5300 (the DNS server runs on that port)
Destination: any
Destination port: any
Translation/target: PUBLIC_IP
Translation/port: 53

But the rule doesn't work. When I use another port as the translation port, like 54, I can see the rule being executed in the firewall live log. When I use a port, that is used in an active port forwarding rule, the NAT outbound rule is not executed (according to the log) and I receive a timeout error and find a state like "NO_TRAFFIC:SINGLE", doesn't matter which port (so there is not interference the the enabled unbound DNS that is running on the opnsense as a recursive resolver).

I suspect, that there is an issue with the order of the NAT rules being executed, that causes loop and I have to mark the outbound traffic somehow to ignore any port forwarding.

Thank you for your assistance!

3

High availability / CARP virtual IP high packetloss

« on: May 31, 2024, 05:10:06 pm »

I have some issues running my firewall in HA. My network is attached, as well as my CARP setup.

As soon as I start my backup firewall, I experiance a package loss of 10-50% on all virtual IPs of the WAN side. I don't have that issue on the LAN side. There is no package loss accessing the firewalls on their unshared IPs. I tried to test some random vhid, to rule out interference on this by my ISP, but it doesn't work.
As far as I can tell, there is now split brain between both firewalls, the main one is the master, and the backup is slave and the simulated failover works. The switch between the firewalls and the ISP Router (Adtran NetVanta 4660) is an unmanaged TP-Link. I used the same switch on the LAN side, again with no issues.

Thank you!

4

German - Deutsch / CARP vIP Paketverlust

« on: May 30, 2024, 05:43:07 pm »

Moin,

ich habe Probleme meine Firewall hochverfügbar zu bekommen.

Netzaufbau:
Ich habe eine Skizze angehängt: Mein ISP (Telekom) stellt mir einen IP-Block zur Verfügung (W.W.100.0/29), der in einem Router von denen ankommt (Adtran NetVanta 4660). Da der Router nur einen aktiven Port hat, geht dieser in einen Unmanaged TP-LINK Switch, an den die beiden Firewalls angeschlossen sind.

Den IP-Block habe ich wiefolgt verteilt:
- W.W.100.2: CARP virtual IP
- W.W.100.3: Firewall 1
- W.W.100.4: Firewall 2
- W.W.100.5: virtual IP mit gleicher VHID wie .2
- W.W.100.6: virtual IP mit gleicher VHID wie .2

Ich bin den Anleitungen von Thomas Krenn und der Opnsense Doku gefolgt um die zweite Firewall einzurichten.

Problem:
Sobald ich die zweite Firewall hochfahre habe ich einen Paketverlust von 10-50%, sobald ich im WAN-Netz die virtuellen IPs ansprechen (CARP + vIPs). FW1+2 direkt lassen sich ohne Paketverlust anpingen. Von der LAN-Seite gibt sind die CARP-IPs uneingeschränkt erreichbar.

- Die Kabel habe ich alle gewechselt
- Die Ports habe ich gewechselt
- Das Problem betrifft nur WAN, nicht LAN
- Den Switch habe ich auch im LAN problemlos einsetzen können
- Die CARP-IPs werden korrekt verhandelt, es gibt keine Probleme mit Master/Slave Zuweisungen laut Statusseiten, Hin-und Herspringen des Master habe ich auch in den Logs nicht finden können.
- Ich habe mehrere vhids ausprobiert, da laut Dokumentation der Telekom bspw. die 44 und 66 belegt werden können, ohne Erfolg.

Hat jemand eine Idee, woran das liegen kann oder sogar noch besser, wie ich das Problem beheben kann?