Hello.
I might be asking a really simple one, but I don't see any solution.
My status is:
Gateways (attachment 1)
LAN Interface: 192.168.1.1/24, upstream: autodetect (pretty standard)
vodafoneftth Interface: static ip 93.150.60.49/30, upstream gateway 93.150.60.49
Firewall (attachment 2), pretty standard
DHCP LAN: standard, gateway is empty
DHCP vodafoneftth: Disabled
What I want:
People on LAN network should be able to use vodafoneftth to connect to Internet
What happens:
I can connect to LAN, I get an IP from DHCP (192.168.1.10 in my case) but I cannot anything outsite.
I can also ping 93.150.60.49 from my PC. (attachment 3)
What am I doing wrong?
Update:
I set a new gateway (attachment 1)
and a route (attachment 2)
Now the opnsense server can ping to 1.1.1.1 and others.
I cannot still make it work with the LAN computers.
Sounds like a missing outbound NAT. Your private RFC1918 addresses are discarded on first hop, since not routed on Internet.
You have to set up an outbound nat rule to translate your lan addresses to your public wan address.
I was wondering the same thing.
Unfortunately I am not that proficient with networks so I might ask some help.
I set outbound NAT from auto to hybrid and added a rule but I am missing something for sure..
(attachment)
Source must be 'LAN subnet'. You want to masquerade every ip in your subnet - not just the LAN ip of your firewall.
(attachment 1): new rules
I set LAN Net since there is no "lan subnet" as you said
The result is the same (attachment 2)
Right. My fault. It is called. 'LAN net'. So does it work now?
No, ping works, nslookup goes timeout.
I save some more information.
I can ping to 8.8.8.8 from my computer but, if i try to ping it from the opnsense server:
# /sbin/ping -S '192.168.1.1' -c '3' '8.8.8.8'
PING 8.8.8.8 (8.8.8.8) from 192.168.1.1: 56 data bytes
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
Here I have the firewall log. (attachment)
First of all, I would discard those gateways for lan. Usually with DHCP, you let WAN gateway assign via dhcp and set LAN to automatic. In your case, you set the provided provider gateway on WAN and everything else to automatic.
If nslookup does not work, DNS does not work. Check your rules 'allow LAN --> any : 53/udp+tcp'. Check your local dhcp server. Which dns server does it provide?
My ISP set the modem without a DHCP server, I cannot set the WAN gateway to get an IP automatically.
I set DNS to: 91.80.35.134, 91.80.35.166 (which are default vodafone dns servers), my DHCP should use that.
I tried the 53 port rule. Nothing changed (attachment 1)
Attachment 2 contains my route status configuration
Attachment 3 contains dhcp DNS configuration
I have a very interesting log on hat happens when i try a nslookup from my PC
Also, if I curl with my pc to an ip pointed to a simple nginx, this is the reply (attachment 2)
What I mean is your totally crowded and WRONG routing table. Your default gateway is a LAN address, your DNS servers are host routes and your transfer net is routed inside.
Do the following:
- delete all manually configured gateways and routes
- make sure, you do not have any gateways used in firewall rules
- set up 1 (one!) default route with 93.150.60.49 as gateway
- Interface: WAN
- IP-Family: IPv4
- IP-Adress: 93.150.60.49
- Upstream Gateway: Checked
- Select this gateway in Interfaces->WAN->Upstream Gateway
- All other interfaces use: Auto-detect
Your DNS servers are extern. Not know by OPNsense, so default gateway is used anyway. No need for host routes.
I cannot find this particular check: Upstream Gateway
Maybe I am setting up the route in the wrong panel?
Anyway I tried and now I have:
WAN_GWv4 gateway: 93.150.60.49 (attachment 1)
WAN Interface Upstream gateway (attachment 2)
I see that the system set some NAT rules (attachment 3)
And i attach the firewall (attachment 4)
I also restarted everything and cleared firewall status.
Now I cannot ping the internet with my PC (but ping works with WAN from opnsense)
# /sbin/ping -S '93.150.60.49' -c '3' '8.8.8.8'
PING 8.8.8.8 (8.8.8.8) from 93.150.60.49: 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.124 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.048 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.053 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.048/0.075/0.124/0.035 ms
It does not work with LAN
# /sbin/ping -S '192.168.1.1' -c '3' '8.8.8.8'
PING 8.8.8.8 (8.8.8.8) from 192.168.1.1: 56 data bytes
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
Port probe with WAN:
# /usr/bin/nc -w 10 -z -4 -s '93.150.60.49' '8.8.8.8' '53'
Connection to 8.8.8.8 53 port [tcp/domain] succeeded!
Port probe with LAN: (THIS IS INTERESTING)
# /usr/bin/nc -w 10 -z -4 -s '192.168.1.1' '8.8.8.8' '53'
Connection to 8.8.8.8 53 port [tcp/domain] succeeded!
Quote
I cannot find this particular check: Upstream Gateway
Maybe I am setting up the route in the wrong panel?
You are using a legacy version. Current version is 19.7.2 and default gateway is now called "upstream getaway".
Any special reason you set up a new firewall with an old version?
Ping is not stateful. Will not work from lan without an allow icmp echo reply rule on wan.
Use a lan client and simply test internet access.
I am using an old version because it was sold to me like that (deciso hardware), I updated in June or July I think then I switched connection.
I will update to 19.7 when I will get the connection for sure, but I need the connectivity.
Anyway, I already tried testing internet access. No luck.
All my requests timeouts (ping, nslookup, browser).
Using an old still active connection, I am able to upgrade to the next version.
I will let you know if the upgrade succeeds and if everything starts working then.
Using an old connection I managed to update to 19.7.
I updated, reset the whole thing to factory and used the wizard.
I also checked that everything was ok. Now I have the upstream gateway checked.
Still not working.
I am opening the same thread on 19.7 section since I have the right version now.
Sorry, seems to be unresolvable layer 8 problem. I'm out.