Messages

Ups. Hatte ganz vergessen, die Lösung mitzuteilen.

Dieses Verhalten tritt nur auf wenn du in Interfaces : XXX auch ein Upstream Gateway gesetzt hast, oder das Interface ein DHCP Client ist. Dann wird jeden Paket, egal ob es auch ins gleiche Netz geht erst an das Gateway geschickt.


Entweder
- Upstream Gateway austragen -> dann brauchst du manuelle NAT Regeln und ein Gateway

Nachdem ich auf der Schnittstelle igb4 den Punkt IPv4 Upstream Gateway auf "auto-detect" gesetzt hatte, war das Problem gelöst.

Im Rack beim Hoster gab es jetzt nur ein Kabel für den Internetanschluss, wo die alte Firewall dranhing. Deshalb musste ich das über einen kleinen 5Port-Switch lösen, damit ich das parallel einrichten kann. Ich habe also zwei Public-IPs, eine für die alte Firewall und eine zum Testen der neuen Firewall. Die alte Firewall hängt an Port1, die neue Firewall hängt an Port2. Mit einem im LAN angeschlossenen Notebook kam ich ins Internet. Beim Ping auf das WAN-Inteface von außen jedoch keine Antwort.

Ich würde zuerst mal nachsehen, ob überhaupt ein Paket am Interface ankommt. Als root auf der Konsole der OPNsense per tcpdump(1):

# tcpdump -i igb1 -n ip proto \\icmp

eventuell auf die Quell-Adresse des pingenden Notebooks eingrenzen:

# tcpdump -i igb1 -n ip proto \\icmp and host 1.2.3.4

Da alle Regeln ein label haben sind das keine Auto Rules. Komisch.
Also momentan schickt der die Replies and .1 und nicht an .76?

Ja. Genau genommen die ICMP Echo Requests.

Offenbar funkt mir da auch noch das SNAT dazwischen. Kann das die Ursache sein?

Ich habe mal von einem  Host aus dem inneren Netzwerk an die 10.100.0.1 gepingt. Da laufen die Pakete wie folgt:

[192.168.2.60] ----> [igb0:192.168.2.200  OPNsense  igb4:172.17.3.10] ----> [172.17.3.1]

Wenn ich mir die eingehenden Pakete jetzt auf igb0 ansehe:

17:10:24.759013 b4:39:d6:f0:e4:00 > 00:24:1d:72:a7:22, ...: 192.168.2.60 > 10.100.0.1: ICMP echo request, id 30950...

und die von der OPNsene ausgehenden auf igb4:

17:10:19.719023 6c:b3:11:22:2b:b6 > cc:ce:1e:d8:4d:c6, ...: 172.17.3.10 > 10.100.0.1: ICMP echo request, id 55412...

dann greift hier das SNAT auf dem Interface igb4. Die Mac-Adresse cc:ce:1e:d8:4d:c6 ist die von dem Default-Gateway.

Kann das die Ursache sein?

Welcher Interface wäre denn das betroffene? Mach noch das Gleiche für "reply-to" statt "route-to" .. bin grad verwirrt, sorry  :o

Das Setup wurde aus einer gewachsenen Struktur migriert und ist leider etwas komplex und ist grob so aufgebaut. :-/

Es geht um das Interface igb4.


                                              +------------+
                                              |   OPNsene  |
  +------------+                           ---+igb5        |
  |            |172.17.3.1                    |            |
  | Default-GW +--------------+---------------+igb4    igb2+----INTERN
  |            |              |    172.17.3.10|            |
  +------------+              |               +------------+
                              |
                              |172.17.3.76 
                        +-----+------+
                        |            |
                        | Subnetz-GW |         
                        |            |
                        +------------+

Ich habe die PF-Ausgabe mal auf igb4 beschränkt:

pass in log quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from any to 11.22.33.77 port = openvpn flags S/SA keep state label "label1"
pass in log quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from any to 11.22.33.77 port = openvpn keep state label "label1"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from <LW_Service> to (self) flags S/SA keep state label "label2"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from <LW_Service> to (self) keep state label "label2"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from (igb4:network) to (self) port = domain flags S/SA keep state label "label3"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from (igb4:network) to (self) port = domain keep state label "label3"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from any to (self) port = smtp flags S/SA keep state label "label4"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from any to <mailgw2> port = smtp flags S/SA keep state label "label5"
pass in log quick on igb4 reply-to (igb4 172.17.3.1) inet from <OVPN_Transfer> to <Server_Netzwerk> flags S/SA keep state label "label6"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto esp from <SH_IPSec_GW> to (self) keep state label "label7"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from <SH_IPSec_GW> to (self) port = sae-urn flags S/SA keep state label "label8"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from <SH_IPSec_GW> to (self) port = sae-urn keep state label "label8"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from <SH_IPSec_GW> to (self) port = isakmp flags S/SA keep state label "label9"
pass in quick on igb4 reply-to (igb4 172.17.3.1) inet proto udp from <SH_IPSec_GW> to (self) port = isakmp keep state label "label9"
pass in log quick on igb4 reply-to (igb4 172.17.3.1) inet proto tcp from any to 11.22.33.75 port = smtp flags S/SA keep state label "label10"

Wobei ich bei mir ein paar Systeme durchgesehen habe, auch mit pppoe und dhcp und da steht das immer richtig drin:

Die Adressen sind auf dem System statisch konfiguriert.

Kannst du mal auf der Console tippen:

pfctl -s all | grep route-to

Gern.

pass out log route-to (igb2 11.22.33.76) inet from 11.22.33.73 to ! (igb2:network) flags S/SA keep state allow-opts label "label1"
pass out log route-to (igb0 192.168.2.5) inet from 192.168.2.200 to ! (igb0:network) flags S/SA keep state allow-opts label "label2"
pass out log route-to (igb4 172.17.3.1) inet from 172.17.3.10 to ! (igb4:network) flags S/SA keep state allow-opts label "label3"
pass out log route-to (igb5 11.22.33.65) inet from 11.22.33.66 to ! (igb5:network) flags S/SA keep state allow-opts label "label4"
pass in log quick on igb2 route-to (igb4 172.17.3.1) inet from 11.22.33.33 to any flags S/SA keep state label "label5"
pass in quick on igb2 route-to (igb4 172.17.3.1) sticky-address inet proto tcp from <mailgw> to any port = smtp flags S/SA keep state label "label6"
pass out log on igb5 route-to (igb5 11.22.33.65) inet proto udp from any to 62.225.42.158 port = isakmp keep state label "label7"
pass out log on igb5 route-to (igb5 11.22.33.65) inet proto esp from any to 62.225.42.158 keep state label "label8"

Dieses Verhalten tritt nur auf wenn du in Interfaces : XXX auch ein Upstream Gateway gesetzt hast, oder das Interface ein DHCP Client ist. Dann wird jeden Paket, egal ob es auch ins gleiche Netz geht erst an das Gateway geschickt.

Das ist IMHO ein seltsames Verhalten. Womit wird das begründet?

- Upstream Gateway austragen -> dann brauchst du manuelle NAT Regeln und ein Gateway

Wozu benötige ich eine manuelle NAT Regel? Also SNAT?

Wie werden dann die Pakete geroutet, die von der OPNsense ausgehen. Soweit ich das verstanden habe, greifen die Gateway-Routen des Policy Routing in den Firewall Settings nur, wenn ein Paket die OPNsense passiert und nicht direkt auf dem System generiert und verschickt wird.

- Disable Reply-to in Firewall : Settings : Advanced
- Eine FIrewallregel auf dem entsprechenden Interface und in Advanced nur dort den Haken bei "Disable Reply-to" (da muss man mit den Richtungen etwas spielen)

Ok. Das werde ich mal testen.

Vielen Dank und Gruß,
Martin

Hi Jens,

OK wo kommt denn jetzt die .76 her? Oben listest du .1, .10 und .74 auf und jetzt ist das Gateway weiter unten aber die .76? Wer ist das und warum?

Das war ein Fehler. Habe ich korrigiert.

Der Ping wird auf der OPNsense ausgeführt.

  +------------+                              +----------+
  |            |172.17.3.1         172.17.3.10|          |
  | Default-GW +--------------+---------------+ OPNsense |
  |            |              |           igb4|          |
  +------------+              |               +----------+
                              |
                              |172.17.3.76 
                        +-----+------+
                        |            |
                        | Subnetz-GW |         
                        |            |
                        +------------+

[Setup-Übersicht]

Hallo,

ich habe ein Routing-Problem mit einer aktuellen OPNsense Installation. Wenn ich einen Host im Subnetz anpinge, wird das Paket nicht an den Router geschickt, sondern an das Default-Gateway obwohl die Route korrekt gesetzt ist.

Setup-Übersicht

• 172.17.3.1 - Default Gateway
• 172.17.3.10 - Adresse des externen Interfaces (igb4) der OPNsense
• 172.17.3.76 - Gateway für das Subnetz 10.100.0.0/24

Diagnose
# route show 10.100.0.1
   route to: 10.100.0.1
destination: 10.100.0.0
       mask: 255.255.255.0
    gateway: 172.17.3.76
        fib: 0
  interface: igb4
      flags: <UP,GATEWAY,DONE,STATIC>

Ich habe mir die Ethernet-Pakete auf dem igb4-Interface mit tcpdump angesehen.

# tcpdump -e -i igb4 -n ip proto \\icmp and net 10.100.0.0/24                                     
...
10:58:18.584392 6c:b3:11:22:2b:b6 > cc:ce:1e:d8:4d:c6, ethertype IPv4 (0x0800), length 98: 172.17.3.10 > 10.100.0.1: ICMP echo request, id 40277, seq 0, length 64               


Diese werden blöderweise an das Default-Gateway geschickt (cc:ce:1e:d8:4d:c6) anstatt an den 172.17.3.76 (ee:30:5d:8a:54:31)

# arp -a -n | egrep 172.17.3.1\|172.17.3.76
? (172.17.3.76) at ee:30:5d:8a:54:31 on igb4 expires in 365 seconds [ethernet]
? (172.17.3.10) at 6c:b3:11:22:2b:b6 on igb4 permanent [ethernet]
? (172.17.3.1) at cc:ce:1e:d8:4d:c6 on igb4 expires in 1197 seconds [ethernet]


Wie kann ich das weiter Debuggen?
Kann ich das Paket irgendwo im System "verfolgen"?

Edit: IP-Adresse des GW korrigiert.

After some debugging, I found a config issue. Looks as the origin cause of my problem.

The configd daemon has no socket bound!. See above.

After service restart or reboot the problem persits. I've no idea how to solve this problem. Could anyone give me some hints?

# fuser /var/run/configd.pid
/var/run/configd.pid: 65792w
# ps ax | grep 65792
65792  -  Is     0:00.30 /usr/local/bin/python3 /usr/local/opnsense/service/configd.py (python3.7)
47360  0  S+     0:00.00 grep 65792
# ls /var/run/configd*
/var/run/configd.pid

Regards,
Martin

Hallo,

ich habe ein Problem mit dem Configd auf einer OPNsense. Der configd Daemon ist gestartet, hat aber keinen Socket gebunden. In den Logs wird nichts angezeigt.

Wie kann ich das weiter debuggen?

Hier die Tests auf dem System:

# fuser /var/run/configd.pid
/var/run/configd.pid: 65792w
# ps ax | grep 65792
65792  -  Is     0:00.30 /usr/local/bin/python3 /usr/local/opnsense/service/configd.py (python3.7)
47360  0  S+     0:00.00 grep 65792
# ls /var/run/configd*
/var/run/configd.pid

Hello,

I want to create a static route, but the configurated gateway will not shown unter System:Routes:Configuration -> "Edit Route".

Attached screenshots:

• Gateway-Konfiguration
• Edit-Route

OPNsense Version:  20.1.8_1

Can you try https://github.com/opnsense/core/commit/41cf191205cf627f1820bf43c745e324aa04005e ?

Thanks, works perfectly! :-)

Regards,
Martin

[UGLY WORKAROUND]

Hello,

we've installed an OPNsense 20.1.1 system and want to configure the Squid proxy with ldap authentication.
At the web ui, we configured the LDAP server for authentication. The setup is correct because we could see successful bind requests at the ldap server log.

Squid logs an error in /var/log/squid/cache.log:

...  kid1| helperHandleRead: unexpected read from basicauthenticator #Hlpr1, 4 bytes 'OK
'
...  kid1| helperHandleRead: unexpected read from basicauthenticator #Hlpr1, 4 bytes 'OK
'

This is our proxy auth module configuration at the system:

# grep -r auth_ /usr/local/etc/squid/|grep -v '#'
/usr/local/etc/squid/squid.conf:auth_param basic program /usr/local/libexec/squid/basic_pam_auth -o
/usr/local/etc/squid/squid.conf:auth_param basic realm OPNsense proxy authentication
/usr/local/etc/squid/squid.conf:auth_param basic credentialsttl 2 hours
/usr/local/etc/squid/squid.conf:auth_param basic children 5

But the proxy auth module sends an additional line.

# echo 'martin VerySecurePassword'|/usr/local/libexec/squid/basic_pam_auth -o
{"dn":"uid=martin,ou=People,dc=lwsystems,dc=intern"}
OK

The line starting with {"dn":"... causing the error.

UGLY WORKAROUND

We moved the file basic_pam_auth to basic_pam_auth_ORG and created a wrapper script.

Content of wrapper script:

#!/usr/local/bin/perl
#
#
$|=1;  # no buffering on STDOUT

while (<STDIN>) {
  open AUTH, '|/usr/local/libexec/squid/basic_pam_auth_ORG | grep -v "dn"';
  print AUTH $_;
  close AUTH;
}

mv  basic_pam_auth basic_pam_auth_ORG
vi basic_pam_auth
chmod 0755 basic_pam_auth

Edit: Workaround added.

Regards,
Martin

Same Problem here with my Firewall at Home and at Work.
Unable to clear some Lines from the Whitelist.

Seems that OPNsense has some Problems with Special Characters?!

Any Help would be appreciated.

As a workaround you could edit the HTML-Page "directly" with the developer tools of your browser.
In Firefox click inside the White- or Blacklist text field.
Then   right-click and select Inspect Element. Inside the inspector tool you open the
<ul class="TokensContainer">
You see the list of entries. Select the entry to delete, right-click and "delete node".
Close the inspector and apply the changes at the web page.

Regards,
martin!