VIP WAN kann von außen nicht angepingt werden

[tbarth]

Hallo,

ich beschäftige mich erst seit etwa 2 Wochen mit OPNSense ('20.1.8'). Ich möchte OPNSense auf zwei Supermicros einrichten, um endlich eine alte IP-Cop Firewall abzulösen. Ein gewisses Basis-Verständnis ist also vorhanden. Aber mein Verständnis reicht nicht aus, um ein Problem zu beseitigen, welches beim Testen der Konfiguration auftritt. Ich kann von außen einfach nicht das WAN-Interface über die virtuelle Public-IP anpingen, aber im LAN schon! Und vielleicht kann mir einer von euch sagen, was ich da so falsche mache.
Ich möchte nur ein einfaches Basis-Setup. LAN mit einer handvoll Hosts, OpenVPN über WAN, Portforwarding für bestimmte Source-IPs, Namensauflösung. Einmal konfiguriert und für die nächsten 20 Jahre nicht mehr anfassen :)

Zur Konfiguration Node 1
#1 (igb0)   LAN (green) 192.168.2.101/24
#2 (igb1)   WAN (red)   172.18.0.101/24
#3 (igb2)   PFSYNC Direct-Cross-Connect   10.0.0.1/24 (noch nicht eingerichtet)

Im WAN 83.125.x.x/24 als virtuelle floating IP (vhid1, freq. 1/0, WAN, CARP)
Im LAN die 192.168.2.1/24 als virtuelle floating IP (vhid3, freq. 1/0, LAN, CARP). Hosts im LAN sollen diese als Gateway/Nameserver nutzen

Outbound-NAT für das WAN
Interface WAN Source 192.168.2.0/24  NAT Address 83.125.x.x

Gateways Single
WAN 83.125.x.1 Default Gateway

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.
Auch als ich die Firewall bei mir zuhause an meine Fritzbox anschloss, konnte z.B. die IP 192.168.178.25 (VIP WAN) nicht angepingt werden, obwohl ich in der Netzwerkübersicht der Fritzbox gesehen habe, dass die IP benutzt wird. Hier ist mir nur aufgefallen, dass das Interface, das an der Fritzbox angeschlossen ist, Orange leuchtet (mehrere Kabel ausprobiert). Ich kann nun leider nicht sagen, ob die LED auch schon im Rack beim Hoster Orange leuchtete, da ich das nicht sehen konnte.

Kann man von dieser Beschreibung her schon sagen, was das Problem sein könnte? Oder sind noch weitere Informationen erforderlich?

Über eine Hilfestellung würde ich mich freuen!

Gruß
Thomas B

[superwinni2]

Einmal konfiguriert und für die nächsten 20 Jahre nicht mehr anfassen :)

Na dann würde ich aber an deiner Stelle die Finger von jeglicher Sicherheitssoftware lassen...




Hast du Regeln auf dem WAN Interface angelegt, um den Ping auch zuzulassen? Davon kann ich leider nichts lesen...

[mwerth]

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

[tbarth]

Danke euch, PING funktioniert nun. Ich wusste nicht, dass ICMP standardmäßig blockiert wird. Ich hatte das so interpretiert, dass das Interface gar nicht erreichbar ist. Da ich den Server derzeit zuhause an der Fritzbox habe, musste ich auch noch auf WAN "Block private network" deaktivieren. Ich werde das natürlich wieder aktivieren, wenn ich den Server im Rack unterbringe.

Proto           Source                   Port    Destination                Port    Gateway    Schedule    Description   
IPv4 ICMP        *                           *              *                            *            *             ICMP for all 

In der Konsole sehe ich dann im Moment:

IP 192.168.178.105 > 192.168.178.30 ICMP echo reply ...
IP 192.168.178.1 > 192.168.178.30 ICMP redirect .. to host 192.168.178.105

[superwinni2]

Na dann klappt ja alles


Viel Erfolg mit der neuen Firewall!

[tbarth]

Naja, ich musste gerade alles neu machen und die Factory Defaults über die Konsole laden, weil ich die Firewall mit einer falschen Einstellung bei DHCP komplett blockiert habe. Ich dachte, ich könnte dort ein paar statische ARP Einträge vornehmen, um Host bekannt zu machen. Die Clients im LAN sollen die IP 192.168.2.1 als Gateway/Nameserver nutzen. Die Auflösung von Domains klappte soweit, aber das Hinzufügen von einfachen Hostnamen wie oms1, oms2 usw mit entsprechende MAC-Adresse führte dann zur totalen Blockade. Wie gut, dass ich damit noch experimentieren kann.
Wie ich gerade gesehen habe, kann man auch Backups anlegen und diese über die Konsole einspielen. Das werde ich mir dann auch mal angewöhnen, vor einer neuen Änderung ein Backup anzulegen. Muss die Backup-Datei dann auf einen USB-Stick oder kann ich die Backup-Datei jedesmal per ssh übertragen?

[micneu]

backups kannst du auch über die webgui machen, dann werden diese auf deinem rechner übertragen

[tbarth]

backups kannst du auch über die webgui machen, dann werden diese auf deinem rechner übertragen

Hier war es nun so, dass ich nach der Aktivierung von "Static ARP entries" bei DHCP LAN gar keinen Zugriff mehr auf die Web-GUI hatte, da ich nicht meinen Client eingetragen hatte, sondern nur "ergänzend" einen Host, der noch gar angeschlossen war. Sollte nur eine Vorbereitung sein.
Aber von der Konsole kann ich wohl auch nur automatisch angelegte Backups wiederherstellen und kann dort keine Datei auswählen.