Messages

Hallo,

ich habe das selbe Problem wie in
https://forum.opnsense.org/index.php?topic=27814.msg137798

OPNsense 23.7.9

lan 
ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 128, id 57613, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 4c:d7:17:74:de:d9, length 300, xid 0x7db49ff6, secs 1024, Flags [Broadcast] (0x8000)
     Client-Ethernet-Address 4c:d7:17:74:de:d9
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message Option 53, length 1: Discover
       Client-ID Option 61, length 7: ether 4c:d7:17:74:de:d9
       Hostname Option 12, length 6: "xxxx"
       Vendor-Class Option 60, length 8: "MSFT 5.0"
       Parameter-Request Option 55, length 14:
         Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
         Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
         Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
         Classless-Static-Route-Microsoft, Option 252

--> ovpn Tunnel
length 332: (tos 0x0, ttl 64, id 30160, offset 0, flags [none], proto UDP (17), length 328)
    172.31.4.10.67 > 172.xx.xx.xx.67: [udp sum ok] BOOTP/DHCP, Request from 4c:d7:17:74:de:d9, length 300, hops 1, xid 0x7db49ff6, secs 1024, Flags [Broadcast] (0x8000)
     Gateway-IP 172.29.3.1
     Client-Ethernet-Address 4c:d7:17:74:de:d9
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message Option 53, length 1: Discover
       Client-ID Option 61, length 7: ether 4c:d7:17:74:de:d9
       Hostname Option 12, length 6: "xxxx"
       Vendor-Class Option 60, length 8: "MSFT 5.0"
       Parameter-Request Option 55, length 14:
         Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
         Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
         Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
         Classless-Static-Route-Microsoft, Option 252
       Agent-Information Option 82, length 6:
         Circuit-ID SubOption 1, length 4: igb2

<-- ovpn Tunnel  Antwort
length 341: (tos 0x0, ttl 126, id 31497, offset 0, flags [none], proto UDP (17), length 337)
    172.xx.xx.xx.67 > 172.29.3.1.67: [udp sum ok] BOOTP/DHCP, Reply, length 309, xid 0x7db49ff6, Flags [Broadcast] (0x8000)
     Your-IP 172.29.3.20
     Server-IP 172.
     Gateway-IP 172.29.3.1
     Client-Ethernet-Address 4c:d7:17:74:de:d9
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message Option 53, length 1: Offer
       Subnet-Mask Option 1, length 4: 255.255.255.0
       RN Option 58, length 4: 1800
       RB Option 59, length 4: 3150
       Lease-Time Option 51, length 4: 3600
       Server-ID Option 54, length 4: 172.xxxx
       Default-Gateway Option 3, length 4: 172.29.3.1
       Domain-Name-Server Option 6, length 8: 172.xxxxxx
       Domain-Name Option 15, length 9: "xxx.xxxt^@"
       Agent-Information Option 82, length 6:
         Circuit-ID SubOption 1, length 4: igb2

und nun fehlt der Offer Broadcast ins LAN Netz

gibt es hierfür bereits eine Abhilfe, was kann ich tun.
Besten Dank

Gruß
Norbert

Hallo,

noch ein paar Infos.
lokales Netz          172.27.x.x
remoute Netz        172.30.x.x
OPNsense WAN     192.168.4.10

Paketaufzeichnung Ping von Rechner:
  OPNsense Schnittstelle: IPsec
    16:40:47.122805 (authentic,confidential): SPI 0xcca7f8a1: IP 172.27.1.6 > 172.30.2.15: ICMP echo request, id 1, seq 136, length 40
    16:40:47.167410 (authentic,confidential): SPI 0xc3c30a8d: IP 172.30.2.15 > 172.27.1.6: ICMP echo reply, id 1, seq 136, length 40
  OPNsense Schnittstelle: WAN
    16:45:10.204434 IP 192.168.4.10 > 172.30.2.15: ICMP echo request, id 27146, seq 486, length 64
  Aufzeichnung im WAN Netz
    17:03:06.164580 IP 192.168.4.10 > 172.30.2.15: ICMP echo request, id 27146, seq 1509, length 64
    17:03:06.669683 IP 192.168.4.10.4500 > 188.194.137.196.4500: UDP, length 96
    17:03:06.713170 IP 188.194.137.196.4500 > 192.168.4.10.4500: UDP, length 96

Paketaufzeichnung Ping von FW localhost:
  OPNsense Schnittstelle: IPsec
    nichts
  OPNsense Schnittstelle: WAN
    16:51:30.331216 IP 192.168.4.10 > 172.30.2.15: ICMP echo request, id 27146, seq 848, length 64
  Aufzeichnung im WAN Netz
    17:06:59.815813 IP 192.168.4.10 > 172.30.2.15: ICMP echo request, id 55503, seq 2, length 64
    17:07:00.022548 IP 192.168.4.10 > 172.30.2.15: ICMP echo request, id 27146, seq 1732, length 64
    17:07:01.086139 IP 192.168.4.10 > 172.30.2.15: ICMP echo request, id 27146, seq 1733, length 64

Was auffällt,
1. der Ping vom Rechner aus geht und läuft über den Tunnel, aber trotzdem taucht auf dem WAN Netz ein
  192.168.4.10 > 172.30.2.15: ICMP echo request auf.
2. Bei einem Ping von der OPNsense gehen die Daten überhaupt nicht über den Tunnel sondern über WAN

Routen
ipv4   default         192.168.4.254   UGS   23277   1500           igb0   wan   
ipv4   127.0.0.1               link#6      UH   8306           16384   lo0       
ipv4   172.27.1.0/24      172.27.255.2   UGS   1828           1500           igb2   LAN   
ipv4   172.27.255.0/29   link#3      U   0           1500           igb2   LAN   
ipv4   172.27.255.1      link#3      UHS   105           16384   lo0       
ipv4   172.30.0.0/16      192.168.4.254   US   20044   1500           igb0   wan   
ipv4   192.168.4.0/24      link#1      U   2           1500           igb0   wan   
ipv4   192.168.4.10      link#1      UHS   0           16384   lo0   

Hallo,

habe IPsec eingerichtet und Tunnel steht. Verbindung von LAN klappt in beide Richtungen.
Was ich nicht hin bekomme, Verbindung von der Firewall in entferntes Netz.
Also z.B. DNS, Ping, ... aus OPNsense zum entfernten Netz.

Was ich gefunden habe
https://www.netgate.com/docs/pfsense/vpn/ipsec/accessing-firewall-services-over-ipsec-vpns.html
Wenn ich dies so einstelle bekomme ich beim Ping
PING 172.30.1.1 (172.30.1.1): 56 data bytes
36 bytes from 172.27.255.2: Redirect Network(New addr: 172.27.255.1)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 ffe9   0 0000  40  01 2283 172.27.255.1  172.30.1.1

36 bytes from localhost (127.0.0.1): Time to live exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 ffe9   0 0000  01  01 6183 172.27.255.1  172.30.1.1



Gibt es hier einen Trick oder habe ich etwas übersehen.


OPNsense 18.7.1_3

Besten Dank
Norbert

Hallo,

Ausgangssituation:
LAN: 172.30.255.1 dahinter befindet sich ein Layer 3 Switch mit mehreren Netzen. Defaultroute des Switchs auf 172.30.255.1 eingestellt.
Gateway LAN "GW_LAN" mit Gatewayadresse des Switches hinzugefügt.
Routen der internen Netze hinzugefügt mit Gateway Adresse "GW_LAN".

Bis Version 18.7 hat alles funktioniert. Seit Version 18.7, auch mit 18.7.1 kann keine Verbindung mehr auf WAN gemacht werden. Direkt von der FW aus geht es.

Ursache hierfür ist, dass bei den Automatische ausgehende NAT Regelgenerierung nicht mehr die selbst erstellten Routen eingetragen werden.
Werden diese von Hand "Hybride Erstellung ausgehender NAT Regeln" eingetragen, so verhält sich die FW wieder wie vorher.

Ist dies beabsichtigt ?

Beste Grüße und Dank
Norbert

Hallo Franco,

hab vielen Dank und sage bitte dem Team "vielen Dank".

Habe es mit den alten Einträgen getestet und keine Probleme damit.

Besten Dank
Norbert

Problem gefunden.

Wir hatten einen Hosts-Alias, in dem Einträge enthalten waren, die nicht mehr per DNS aufgelöst werden konnten.
Nachdem diese Einträge entfernt wurden, hat OPNsense alle Aliase, die danach kamen wieder ausgeführt.

So wie es aussieht, kommt es dabei zu raise NoNameservers(request=request, errors=errors) und die restlichen Aliase werden nicht mehr abgearbeitet.

Bitte diesen Fehler bereinigen, da nie ausgeschlossen werden kann, dass eine DNS Auflösung abbricht.

Gruß und besten Dank
Norbert

/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py
Traceback (most recent call last):
  File "/usr/local/opnsense/scripts/filter/update_tables.py", line 122, in <module> alias_content = alias.resolve()
  File "/usr/local/opnsense/scripts/filter/lib/alias.py", line 225, in resolve for address in address_parser(item):
  File "/usr/local/opnsense/scripts/filter/lib/alias.py", line 118, in _parse_address for rdata in
      self._dnsResolver.query(address, record_type):
  File "/usr/local/lib/python2.7/site-packages/dns/resolver.py", line 947, in query
    raise NoNameservers(request=request, errors=errors)
 
  dns.resolver.NoNameservers: All nameservers failed to answer the query xxxxx IN A: Server 127.0.0.1 UDP port 53 answered SERVFAIL; Server 172.xx.x.x UDP port 53 answered SERVFAIL

so nun OPNsense 18.1.6 neu aufgesetzt, dann Update auf 18.1.11, dann Konfiguration aus 17.7.12 eingespielt.

--> gleiches Verhalten

Hallo,

ich habe nun von 17.7.12 auf 18.1.6 und dann auf 18.1.11 aktuallisiert.
Nun habe ich das Problem, dass Aliase nicht zu 100% übernommen werden.
Wenn ich in pf-Tabellen nachschaue, sind einige leer. Nicht alle, aber sehr viele.
Gibt es hierfür einen Workaround oder was kann ich tun?

Info: die Maximale Firewalltabelleneinträge stehen auf 1000000


Besten Dank
Norbert

I have found the Problem.

The problem is the Browser.
Google Chrome not work.
IE or Firefox work fine.

BR
Norbert

Hello,

I have a Peer-to-Peer tun-style OpenVPN.
I can Ping from OPNsense OpenVPN server to OPNsense OpenVPN client. But i can't connect to WebGUI.
At the Browser the Error: Diese Seite funktioniert nicht 172.28.255.1 hat keine Daten gesendet.
ERR_EMPTY_RESPONSE

I can connect to all clients in the LAN.

At the Firewall rules OPENVPN is
allow any to This Fireall
allow any to lan

In the Log is pass.

Since this is our branch I have to do the maintenance from the outside.
Does this have anyone an idea what I can still look.

Best regards
Norbert