Messages

Eure Probleme mit IPv6 hören sich ja gar nicht gut an. Ich hatte gehofft es liegt an mir und dass man mir hier im Forum mal eben "kurz" helfen kann. Das witzige ist ja IPv6 wird von opnSense und auch pfSense seit Jahren unterstützt. Auf meiner Suche nach Lösungen bin ich auf Beiträge aus dem Jahr 2011 gestoßen... kann doch nicht sein dass die IPv6 Unterstützung bis heute so Fehlerhaft ist? Ich vermute mal das liegt hauptsächlich daran dass kaum jemand IPv6 aktiv nutzt, und somit viele Probleme/Fehler in den unterschiedlichsten Konfigurationen nicht auffallen.

Ich habe jetzt erst mal den Clients eine feste IPv6 zugewiesen und via ifupdown den default Gateway gesetzt. Eine automatische Adresszuweisung und registrierung im Ubound wäre aber natürlich viel besser...

Hallo zusammen,

ich habe von meinem hoster ein /64 IPv6 Subnetz bekommen. Ich habe dem WAN und dem LAN interface jeweils eine IPv6 statisch zugewiesen. Somit kann ich beide IPs von extern anpingen.

Jetzt möchte ich den Clients via dem integrierten DHCP Server IPv6 Adressen zuweisen lassen. Dazu habe ich auf dem LAN interface den DHCPv6 Server aktiviert und die entsprechende range aus meinem /64 Netz eingetragen. Die Clients bekommen zwar eine IPv6 Adresse zugewiesen, jedoch wird kein default Gateway gesetzt. Somit kommen die Clients nicht via IPv6 ins Internet. Irgendwo habe ich dann gelesen dass man wohl noch den Router Advertisement einschalten und auf "Managed" setzen soll. "Advertise Default Gateway" ist auch standardmäßig aktiviert. Danach habe ich das lease auf dem Client erneuert. Trotzdem wurde kein Gateway gesetzt. Wenn ich die default route via "ip route" manuell setze dann klappt es auch mit der Verbindung nach außen. Von außen kann ich den Client dann auch problemlos anpingen.

Was mir noch Probleme bereitet ist die statische Adresszuweisung via DHCPv6 Mapping. Trotz korrekt hinterleger DUID bekommen die Clients immer eine andere IP zugewiesen.

Das nächste Problem was ich habe ist dass der DHCP Server Dienst immer wieder mal einfach so abstürzt bzw. gestoppt wird. In den Logfiles unter "Services -> DHCPv4" stehen auch keine Fehler oder ähnliches.
Dadurch hängen dann meine Linux Clients minutenlang beim booten weil der DHCP Server nicht erreichbar ist (wieso systemd beim booten standardmäßig bis zu 6 Minuten auf den DHCP Server wartet und wie man das abschaltet muss ich auch noch herausfinden)

Offensichtlich mache ich etwas grundlegend falsch. Ich hätte nicht gedacht dass das einrichten von IPv6 so ein komplizierter Akt wird. Sitze hier schon seit Stunden dran und komme einfach nicht weiter. Kann mir bitte jemand erklären wie man das ganze korrekt konfiguriert?

Thanks, as I wrote the CSRF check failed because for some reason my browser didn't store the cookie. Restarting my browser solved the issue.

I figured it out, so NAT reflection is what I want and then I had to enable "Automatic outbound NAT for Reflection"  in "Firewall -> Settings -> Advanced".... somehow I didn't see this option the whole time.

I have 1 WAN interface with 1 main WAN IP plus one additional WAN IP set up as a virtual IP on the WAN interface.

On the LAN side I have one web server (srv1.example.org) with LAN IP 10.0.0.10. To make it reachable from the outside I set up a NAT portforward with WAN IP 1 as destination and destination ports 80 and 443. Now I can reach srv1.example.org over WAN IP 1

Then I have another web server (srv2.example.org) with LAN IP 10.0.0.20. I want to assign WAN IP 2 to this server, so I set up a 1:1 NAT rule and opened the appropriate ports in the firewall. I have disabled NAT reflection because otherwise the ACME LetsEncrypt client will fail to verify the DNS name (it will then see the LAN IP instead of the WAN IP). So far so good, I can now also reach srv2.example.org over WAN IP 2

So from the outside all is good, I can reach both webservers individually over port 80/443.

BUT my problem now is that if I try to access srv2.example.org from within the LAN, I get served the website of srv1.example.org instead.  I assume this must be an outbound NAT problem. I tried to add a manual outbound NAT rule with different destination/NAT address combinations (e.g. destination WAN IP 2, NAT address 10.0.0.20) with no luck. At this point I don't know what to do anymore. I'd appreciate any help.

I figured it out. I noticed that the PHPSESSION cookie was not stored in my browser (Chrome) for whatever strange reason, even though the cookie was present in the response headers. So I tried it in Firefox, and it works! Chrome Incognito mode works strangely too. Anyway now opnSense complained about an invalid HTTP_REFERER, so I had to adjust the nginx config accordingly.

Here is the minimal nginx config I used to reverse proxy the opnSense web UI, in case anyone needs it. I used the snakeoil cert since it is just temporary.

Code Select Expand


server {
  listen 80;
  server_name your.domain.com;
  return 301 https://$server_name/$1; 
}

server {
  listen 443 ssl;
  server_name your.domain.com;
  ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
  ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;

  location / {
    proxy_buffer off;
    proxy_set_header Host 10.0.0.1; # required to avoid DNS rebind attack warnings
    proxy_set_header Referer http://10.0.0.1; # require to avoid wrong HTTP_REFERER warnings
    proxy_pass http://10.0.0.1;
  }
}


But I'd still like to know if it is possible to disable the web UI security checks from the command shell or not.

Hi,

I'm currently experiment with pfSense and opnSense to see which I like better. I successfully evaluated pfSense and now I want to try opnSense. My goal is to route all traffic to my Proxmox host through a router/firewall VM. My host is installed on a dedicated server with a public IP, I have no LAN access.

I setup the opnSense VM with a private LAN IP (10.0.0.1/24), then I setup NAT port forwarding from the host to the opnSense VM. This way I'm able to access the opnSense Web UI through the public IP of the host, but I immediately got to see the DNS rebind attack warning message.

I solved the DNS rebind issue by installing a nginx reverse proxy in another VM on the same LAN as opnSense, disabling HTTPS
(to avoid SSL passthrough issues) and setting up the appropriate port forwards to nginx instead of opnSense directly. Now I see the login form, but after login I get the "CSRF check failed" message. So many security layers...  ;D

So my question is, can I somehow disable the CSRF checks through the command shell? In pfSense for example I was able to disable the dns rebind attack check through their php developer shell, but I didn't find anything similar in opnSense.
Or do you maybe have another idea how I could access the web UI without triggering dns rebind/CSRF warnings? (with the constraint that I have to use the public IP)