Messages

Перевод Google, поэтому извиняюсь за любые ошибки.

Возможно, вы настроили только правила брандмауэра, но не исходящий NAT? Это значит, что трафик разрешен, но нет правила для перенаправления трафика.

Это всего лишь предположение, но я думаю, что если вы хотите, чтобы весь исходящий трафик на порту 80/443 проходил через 127.0.0.1:8080, то вам нужно настроить исходящий NAT в вашем брандмауэре. По сути, порт назначения 80 или 443, любой пункт назначения, отправляйте его на порт localhost (целевой IP)?

Не забудьте также перенаправить трафик DNS или запустить собственный DNS-сервер локально, который использует внешний, нецензурируемый, защищенный DNS-сервер через зашифрованное соединение. Вы же не хотите, чтобы ваши DNS-вопросы просочились к интернет-провайдеру, цензуру которого вы пытаетесь обойти.

Удачи.

If I ping 192.168.1.1 i get a response

I really don't understand what you're doing, why are you pinging 192.168.1.1 on the opnsense machine itself in one of your screenshots? Of course it's going to respond, that's the IP on one of the interfaces on that machine, it doesn't troubleshoot anything.

Well, if your browser is giving you a proxy error it sure sounds like it's using a proxy. The benefit of testing with curl is that if there are any proxy settings in your browser, they likely won't apply to curl.

Regardless, it's not getting a "correct" response but one that you have overridden somewhere, which you can probably verify by running a command that specifies the DNS server that you want to ask, in this example Google:

# dig @8.8.8.8 lancache.steamcontent.com

(...)
;; QUESTION SECTION:
;lancache.steamcontent.com.     IN      A

;; ANSWER SECTION:
lancache.steamcontent.com. 2775 IN      CNAME   origin-tier2.steampipe.steamcontent.com.
origin-tier2.steampipe.steamcontent.com. 95 IN CNAME steampipe-origin-tier2.steamcontent.com.
steampipe-origin-tier2.steamcontent.com. 112 IN CNAME cache-origin.steampipe.steamcontent.akadns.net.
cache-origin.steampipe.steamcontent.akadns.net. 60 IN CNAME dist-sto1.discovery.steamserver.net.
dist-sto1.discovery.steamserver.net. 24 IN A    162.254.198.12
dist-sto1.discovery.steamserver.net. 24 IN A    162.254.198.13

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8 ) (UDP)
;; WHEN: Thu Aug 15 17:29:45 CEST 2024
;; MSG SIZE  rcvd: 266

You're getting your response from 127.0.0.11 which I assume is the docker-compose internal DNS, which in turn (unless configured otherwise) probably just gets the response from whatever DNS you have configured your system to use.

Whether that is unbound, or pi-hole forwarding requests to unbound, or something else I have no idea since you haven't provided any information on how you have set this up (or what role opnsense plays in it).

As I said, it's getting it from somewhere, since there is no public A-record for steamcontent.com, so either it's configured by you in unbound or pihole, or you're getting the DNS records from an external DNS service that allows you to set the override there.

If I ping 192.168.1.1 i get a response, when i try to open the web gui it doesn't load, gives me proxy error and no internet.

Proxy error? Why are you using a proxy?

What output do you get if you curl the web ui? Example:

curl --silent --insecure https://192.168.1.1 | grep -m 1 title
    <title>Login | OPNsense</title>

I'm personally strongly opposed to using Discord for open source projects. This forum is searchable and within the control of the opnsense project itself (I presume), while Discord is none of those things. Every question and answer given on Discord, or any other walled off proprietary garden, is a question and answer that no one else but that isolated community can view or comment on.

If this is happening between two people that wouldn't use the forum anyway, fine I guess, but I think awareness is needed that this type of community can lower the quality of "open" (searchable) alternatives, like forums.

This is nothing new of course, the same argument could be had against IRC or whatever, but it's still perfectly valid in my opinion. Forums are invaluable, organic knowledgebases that grow over time. They shouldn't be replaced or even amended with something that doesn't bring the same benefits.

My five cents, anyway.

10.x.x.136-254 is the 10.x.x.128/25 subnet, if you have set that on the interface in opnsense it's not surprising that devices outside of that subnet cannot talk to opnsense.

I originally tried making my original/legacy gateway address 10.x.x.3 the same gateway on Opnsense; however it kept setting up the Web Gui with the same address which seemed to interfere also with the LAN address range 10.x.x.1-10.x.x.254 I was using.

Maybe I just don't understand what you mean, but this makes no sense to me. Why not just set your subnet to 10.x.x.0/24? Why would having the opnsense web gui on 10.x.x.3 "interfere" with the "LAN address range"? It's within the /24 range which sounds like what you want since you're surprised when devices in that range can't connect.

If you have a router in AP mode, I assume it's "bridged" (i.e. the AP itself does not have an IP address), so it would help if you specify what exactly you mean by "losing connection" and what does and does not resolve the issue.

Your config file states:

include: /etc/unbound/a-records.conf

That's the first place I would look. Clearly your DNS server is getting this record from somewhere.

Also, since you know you're looking for the string "steamcontent.com" you could just do something like:

grep -rni "steamcontent" .

...to recursively show all files containing that string wherever you have your config files.

I figure on the OpnSense, the WAN's IP should be on the 192.168.1.x series

No. The WAN port is facing your ISP. It should not be using a local IP. Since you mentioned in your first post that this is a PPPoE connection, the "IPv4 Configuration type" for WAN should probably be set to PPPoE.

The WAN port is where you should expect to see an external "internet" IP in your opnsense GUI. You should not have to set up gateway, IP or anything else manually, but since this is PPPoE you probably need some assistance from your ISP regarding authentication, so ask them.

LAN's IP should be on the WAN's IP

I have no idea what this means, but if you mean that they should have the same range then the answer is no, and they should certainly not be bridged.


                       
    192.168.1.1/24     
        ▲             
        │             
      LAN port         
        ▲ DHCP service 
   ┌────┼────┐         
   │opnsense │         
   └────┬────┘         
        ▼             
      WAN port (example: 93.184.215.14)         
        │ PPPoE - DHCP IP from your ISP (probably)       
        ▼             
    ┌─────────┐         
    │ISProuter| (BRIDGED / PASS-THROUGH)
    └───┬─────┘         
        ▼             
      Internet         
                       


First make sure you succeed in getting an external IP on a non-bridged WAN-interface. At that point, I believe with default configs you should be able to access the internet from your LAN net, but if not troubleshoot from there.

No local IP -> Is DHCP service running?
No Internet access -> Does the firewall allow it?

etc.

I watched an online video and bridged the LAN and WAN on OpnSense, but that work either.

Why would you want to bridge WAN and LAN in opnsense? If you want it to be a router, you certainly do not want those interfaces to be "one interface", you want them to be separate because WAN is where "the internet" comes in, and LAN is where your local network will talk to opnsense that normally runs a DHCP server to assign them internal IP addresses.

If I don't misremember, the creation of a LAN port and a WAN port is done out of the box in opnsense, and I believe it also runs a DHCP server so you shouldn't have to do anything except connect "the internet" to the WAN port and "the local network" to LAN. If you didn't try that before making configuration changes, maybe try that first.

I have a bridge in my setup, but that's because I have more than two ethernet ports, so I bridge multiple LAN ports together so they all can be used to connect devices "behind" the router.

After bridging on th router, does the cable from the LAN port of the router goes into the WAN of OpnSense?

Yes.

And another cable from the other RJ45 port of OpnSense to the network switch?

Yes.

If so, does the OpnSense WAN get IP via DHCP of the fibre optic router or should i put a static?

Impossible to answer because it depends on your ISP, but almost all ISPs give out IP via DHCP, not static.

And is the LAN required to be put on a separate subnet?

The IP you get from your ISP will very likely be an external IP address, or if you're unlucky a CGNAT address. Regardless of which it is, your LAN should have it's own subnet (like 192.168.1.1/24) that opnsense will give out IP addresses in to your local devices via its built in DHCP server.

Most "ISP routers" have an option in their settings to bridge the entire device, they're all different but normally this would mean that any device plugged in on any LAN port would get an "external" IP directly, and depending on the ISP you either have one external IP assigned, or multiple. If you only have one, plugging in multiple devices would then lead to either the new one "taking over" the IP, or a new IP, or the new one being unable to connect since there is a DHCP lease for the single external IP available.

The reason I'm mentioning this is that it can become really annoying to troubleshoot if you involve multiple devices behind the bridge and your ISP only allows one IP, so if possible, try not to involve any laptops or other devices when testing out the "bridge" mode of your router, as it may hog the lease and lead to much confusion when opnsense does not get an IP ("it just worked on the laptop" etc). I.e. when bridge mode has been enabled and it restarts (usually), make sure nothing, then your opnsense router, is the only thing plugged in ASAP.

Regardless, if you can bridge your "ISP router", you should be able to have a cable go from one of the LAN ports on that device to the WAN port on your opnsense router, then set it up as normal.

WireGuard shows as connected and up with handshake, but my Client Devices can not use the VPN.

It sounds like the VPN is working just fine, just that client devices can't exit through the VPN interface (wg0 or whatever). Every time I've had issues like this, it's been because there are firewall rules missing, so the traffic is being blocked.

Maybe you can try going to the live view of the firewall logs and based on IP or something check whether traffic is being blocked.

All right, I removed os-dnscrypt-proxy from the gui which also removes dnscrypt-proxy2, I then reinstalled dnscrypt-proxy2 from shell with "pkg install". All the config files were still there, so just had to do "service dnscrypt-proxy start". I'm getting an error when starting the service though, but it doesn't seem to affect the functionality:

# service dnscrypt-proxy start
eval: /usr/local/opnsense/scripts/OPNsense/Dnscryptproxy/setup.sh: not found
/usr/local/etc/rc.d/dnscrypt-proxy: WARNING: failed to setup dnscrypt_proxy
Starting dnscrypt_proxy.

This seems to come from this default entry in /etc/rc.conf.d/dnscrypt_proxy:

dnscrypt_proxy_setup="/usr/local/opnsense/scripts/OPNsense/Dnscryptproxy/setup.sh"

This variable is not mentioned in /usr/local/etc/rc.d/dnscrypt-proxy so I'm not sure what the purpose of it is, I've commented it out for now. Maybe *_setup is just some kind of rc convention, I'm not that used to FreeBSD  :)