1
24.1 Legacy Series / Re: Browser cannot establish a https connection to GUI
« on: February 21, 2024, 06:01:28 pm »
adding float IP as alias to opnsense helped to survive the Referred check :-)
Case solved
Case solved
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
24.1 Legacy Series / Re: Browser cannot establish a https connection to GUI
« on: February 21, 2024, 05:25:11 pm »
omg found it: mtu issue :-) After lowering interface mtu to 1420 it worked. Now the last problem remains that the HTTP Referer check fails
is it possible to disable this check via cli? Or should I add the floating IP as an alias to the opnsense interface to pass this check?
Quote
The HTTP_REFERER "https://REDACTED/" does not match the predefined settings. You can disable this check if needed under System: Settings: Administration.problem is that redacted is the public floating ip about which opnsense itself has no clue
is it possible to disable this check via cli? Or should I add the floating IP as an alias to the opnsense interface to pass this check?
3
24.1 Legacy Series / Browser cannot establish a https connection to GUI
« on: February 21, 2024, 09:07:00 am »
Hi
have a imho very weird problem with a new opnsense setup. The box is a openstack VM with only one interface (WAN). The WAN interface is within a private subnet and we use a public floating ip on provider's side to connect to the outside world. That floating IP acts like a portforward and forwards every traffic to that floating IP to the internal IP of that box. That box can ping to outside and the box can be pinged from outside. But when I try to access the GUI from outside the browser ends in a timeout. I ran tcpdump on both sides (opnsense and my client) and can see that https packets go back and forth on both sides. But browser cannot establish connection. I already disabled packet filtering completely, no change.
Any idea what could be the cause for that? As said tcpdump looks okay so far on both sides. Following a tcpdump from the client's side
REDACTED is the public floating IP of opnsense, always the same correct IP. I'm not the tcpdump pro but for me it looks like answers are coming back on the client's request.
And following a screenshot from tcpdump on opnsense side (redacted my clients public IP)
One question: is is possible to enable SSH without GUI directly from command line? Would like to enable root SSH access (with password) to try to access the GUI via a ssh-tunnel. Just to verify if it works via a tunnel
Thanks for any hint how to more debug to narrow down the source of the problem.
tobi
have a imho very weird problem with a new opnsense setup. The box is a openstack VM with only one interface (WAN). The WAN interface is within a private subnet and we use a public floating ip on provider's side to connect to the outside world. That floating IP acts like a portforward and forwards every traffic to that floating IP to the internal IP of that box. That box can ping to outside and the box can be pinged from outside. But when I try to access the GUI from outside the browser ends in a timeout. I ran tcpdump on both sides (opnsense and my client) and can see that https packets go back and forth on both sides. But browser cannot establish connection. I already disabled packet filtering completely, no change.
Any idea what could be the cause for that? As said tcpdump looks okay so far on both sides. Following a tcpdump from the client's side
Code: [Select]
09:01:12.569669 IP 192.168.0.22.52810 > REDACTED.https: Flags [S], seq 2124490507, win 32120, options [mss 1460,sackOK,TS val 2774329427 ecr 0,nop,wscale 7], length 0
09:01:12.574899 IP REDACTED.https > 192.168.0.22.52810: Flags [S.], seq 3692313351, ack 2124490508, win 65228, options [mss 1452,nop,wscale 7,sackOK,TS val 3147813325 ecr 2774329427], length 0
09:01:12.574937 IP 192.168.0.22.52810 > REDACTED.https: Flags [.], ack 1, win 251, options [nop,nop,TS val 2774329432 ecr 3147813325], length 0
09:01:12.584496 IP 192.168.0.22.52810 > REDACTED.https: Flags [P.], seq 1:640, ack 1, win 251, options [nop,nop,TS val 2774329441 ecr 3147813325], length 639
09:01:12.590093 IP REDACTED.https > 192.168.0.22.52810: Flags [.], ack 640, win 506, options [nop,nop,TS val 3147813340 ecr 2774329441], length 0
09:01:12.596557 IPREDACTED.https > 192.168.0.22.52810: Flags [P.], seq 1441:2632, ack 640, win 511, options [nop,nop,TS val 3147813342 ecr 2774329441], length 1191
09:01:12.596586 IP 192.168.0.22.52810 > REDACTED.https: Flags [.], ack 1, win 251, options [nop,nop,TS val 2774329454 ecr 3147813340,nop,nop,sack 1 {1441:2632}], length 0
REDACTED is the public floating IP of opnsense, always the same correct IP. I'm not the tcpdump pro but for me it looks like answers are coming back on the client's request.
And following a screenshot from tcpdump on opnsense side (redacted my clients public IP)
One question: is is possible to enable SSH without GUI directly from command line? Would like to enable root SSH access (with password) to try to access the GUI via a ssh-tunnel. Just to verify if it works via a tunnel
Thanks for any hint how to more debug to narrow down the source of the problem.
tobi
4
23.7 Legacy Series / Re: Firewall rules on interfaces do not take effect, floating ones do.
« on: January 26, 2024, 05:42:34 pm »
> A host must not have more than one interface configured by DHCP.
it think that depends on what exactly "host" means :-) If host is your opnsense (router) then I would agree to only configure one of the hosts interface via DHCP (mostly WAN/upstream) and all the others statically. But if host means any host inside your network then I'd agree to the others as this is not feasible nowadays. I have multiple hosts with 3 or more interfaces. To manually configure them would really be a pita. One just has to take care that not multiple default routes are pushed and that the interfaces do not share the same broadcast network. But beside from that I see no point to not configure all interfaces of a host via dhcp :-)
it think that depends on what exactly "host" means :-) If host is your opnsense (router) then I would agree to only configure one of the hosts interface via DHCP (mostly WAN/upstream) and all the others statically. But if host means any host inside your network then I'd agree to the others as this is not feasible nowadays. I have multiple hosts with 3 or more interfaces. To manually configure them would really be a pita. One just has to take care that not multiple default routes are pushed and that the interfaces do not share the same broadcast network. But beside from that I see no point to not configure all interfaces of a host via dhcp :-)
5
23.7 Legacy Series / Re: Console stopped during installation (redirected to VGA?)
« on: January 26, 2024, 05:32:36 pm »
have you checked you BIOS settings? Usually it's named something like "console redicrection" or similar
6
23.7 Legacy Series / Re: Unable to access web GUI of a KVM running opnsense 23.7.11
« on: January 26, 2024, 04:25:38 pm »
I'm unfamiliar with terraform but what made me stuck in your kvm config snippet: why forward mode nat on a bridged interface? Usually a briged-to-the-host interface does not require nat as the VM should be in the same network as the host. If it is nat'ed from the host to the VM then usually one need port-forward rules to access ports on the vm from outside the VM
7
23.7 Legacy Series / Re: Different ISP bridging no connectivity between lan or access to wan
« on: January 26, 2024, 04:00:04 pm »
First question that comes into my mind when seeing this:
net.link.bridge.pfil_bridge
net.link.bridge.pfil_local_phys
in my bridged setup I have the first on 1 and the second on 0 which enables filtering on the bridge interface and not the underlying physical interfaces. Usually one want to filter on the bridge interface and not the physical one (at least in my case
)
Quote
rule 5/0(match) block in on bridge0do you have rules on said interface to allow traffic? Also check the settings of the following two system tunables
net.link.bridge.pfil_bridge
net.link.bridge.pfil_local_phys
in my bridged setup I have the first on 1 and the second on 0 which enables filtering on the bridge interface and not the underlying physical interfaces. Usually one want to filter on the bridge interface and not the physical one (at least in my case
)
8
23.7 Legacy Series / if enabling DHCPv6 server it should bind to ports?
« on: January 25, 2024, 11:13:37 am »
I may have a stupid question :-) But I assumed that if I enable dhcpv6 server on an interface and the dhcp6 server starts then it should listen on udp ports 547 and 548? I try to setup my box with a Hurrican Elec ipv6 Tunnel. IPv6 works so far on the box but if I want to enable dhcp6 on the LAN interface it seems not to bind to the two ports. According to process list the dhcp6 server is started
but no bindings to the two ports according to netstat command
is it right that dhcpv6 server should bind to these two ports or not (or at least 547)? So far only ntp and dns are bound to ipv6
Cheers
tobi
Code: [Select]
dhcpd 62800 0.0 0.2 51904 35680 - Ss 10:49 0:00.02 /usr/local/sbin/dhcpd -6 -user dhcpd -group dhcpd -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid bridge2 bridge3 bridge1 bridge0but no bindings to the two ports according to netstat command
Code: [Select]
netstat -f inet6 -n | grep '.547\|.548'
is it right that dhcpv6 server should bind to these two ports or not (or at least 547)? So far only ntp and dns are bound to ipv6
Cheers
tobi
9
23.7 Legacy Series / Re: auto-generated rules seems to block all traffic?
« on: January 05, 2024, 09:53:19 am »Quote
But igb1 isn't/wasn't your WAN interface?true but I believe
that disable that WAN setting also unset the "default" macro that the LAN rule used under advanced/reply-to. I enabled the WAN reply-to setting again and explicitly set the reply-to in the LAN rule to "disabled". Still works :-)My guess is that this default setting works fine if opnsense really is the default gateway for the subnet. But as currently my opnsense is not the gateway and uses a default route to reach the outside it sets the default GW address to the IP of the default and uses that in reply-to. So I bet I can change back the LAN rules to reply-to default as soon as my opnsese replaced the pfsense and acts as default gateway
Again thank you a lot
Cheers
tobi
10
23.7 Legacy Series / Re: auto-generated rules seems to block all traffic?
« on: January 05, 2024, 09:41:22 am »Quote
This doesn't look right:stumpled also over it after sending my previous post. That reply-to target is my current router and not the opnsense. So I set "Disable reply-to on WAN rules" and tada the access works. Just wonder why the default (did not change that setting before) sets a "wrong" reply-to address. Also why this WAN setting is applied to LAN rules?
But anyway it works now and I can go on with the config migration from pfsense to opnsense.
Thanks a lot for your help and have a good one
tobi
11
23.7 Legacy Series / Re: auto-generated rules seems to block all traffic?
« on: January 05, 2024, 09:26:00 am »
direction seem to be correct and also quick is set according to pfctl
Code: [Select]
pass in quick on igb1 reply-to (igb1 192.168.0.1) inet all flags S/SA keep state label "d038f19d181257facbfb9dfd06f5ba32"
pass out quick on igb1 reply-to (igb1 192.168.0.1) inet all flags S/SA keep state label "c38c9c05eb93a192eb2580dde7a38c15"
12
23.7 Legacy Series / Re: auto-generated rules seems to block all traffic?
« on: January 05, 2024, 09:14:41 am »Code: [Select]
just out of curiosity I added the allow any/any IPv4 rule to floating. And tada I can still access if pfctl -e
So for whatever reason the rules on LAN are not evaluated/applied. Any idea what could be the reason for ignoring the rules on LAN. LAN interface is definitely the right one: the one that the traffic comes in (igb1). Can I somehow check with pfctl that the rules shown under LAN in GUI are really bound to the right interface? Even if I configure that floating rule explicitly to LAN interface the access still works
13
23.7 Legacy Series / Re: auto-generated rules seems to block all traffic?
« on: January 05, 2024, 08:22:54 am »
Good Morning
actually I disabled it as I added two rules on LAN as the following (allow IPv4 any/any)
but I still get blocked by the default rule. How comes that such a any/any rule does not match??
One thing I changed in settings is that I enabled filtering on bridges and disabled it on bridge members
Quote
Or, maybe, the pf macro for (self) is not matching your 192.168.0.242 if the anti-lockout rules are present.
.. either way, it seems to be getting caught by the default drop rule. So something isn't matching an allow rule.
actually I disabled it as I added two rules on LAN as the following (allow IPv4 any/any)
but I still get blocked by the default rule. How comes that such a any/any rule does not match??
One thing I changed in settings is that I enabled filtering on bridges and disabled it on bridge members
Code: [Select]
net.link.bridge.pfil_bridge 1
net.link.bridge.pfil_member 0
but as said LAN (igb1) is not member of any bridge. Is it possible that these settings disable filtering on ANY interface? Regardless if it's a member of a bridge or not?
14
23.7 Legacy Series / Re: auto-generated rules seems to block all traffic?
« on: January 04, 2024, 06:30:50 pm »
Hi
> Assuming that .242 is NOT the firewall itself?
wrong That is my firewall's ip on LAN interface and the .12 is my client from which I try to access
Thanks for your hint with the pfctl -s that shows me that my assumption was wrong. It seems to be this rule
My list of interfaces is quite long. As I plan to use this opnsense box as replacment for my pfsense Router at home. So I prepared all the necessary interfaces already (vlan and bridges). But the interface that I use to configure the box atm is the LAN which looks as follows (no vlan or bridge on that)
Routing table is quite small
Thanks a lot for you help and let me know if you need further details
Now out for dogwalk
Cheers
tobi
> Assuming that .242 is NOT the firewall itself?
wrong
That is my firewall's ip on LAN interface and the .12 is my client from which I try to accessThanks for your hint with the pfctl -s that shows me that my assumption was wrong. It seems to be this rule
Code: [Select]
root@home-opnsense:~ # pfctl -s rules -vv | grep -A 2 ^@8\ block
No ALTQ support in kernel
ALTQ related functions disabled
@8 block drop in log inet all label "02f4bab031b57d1e30553ce08e0ec131"
[ Evaluations: 160 Packets: 24 Bytes: 1872 States: 0 ]
[ Inserted: uid 0 pid 55655 State Creations: 0 ]
no idea what this rules does it's not one of mines :-)My list of interfaces is quite long. As I plan to use this opnsense box as replacment for my pfsense Router at home. So I prepared all the necessary interfaces already (vlan and bridges). But the interface that I use to configure the box atm is the LAN which looks as follows (no vlan or bridge on that)
Code: [Select]
igb1: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN (opt17)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,NOMAP>
ether 20:7c:14:f0:8b:68
inet 192.168.0.242 netmask 0xffffff00 broadcast 192.168.0.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
it's about 29 interfaces we're talking about. I can send you the whole ifconfig output if you like but as said currently only LAN interface is in use.Routing table is quite small
Code: [Select]
root@home-opnsense:~ # netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.0.1 UGS igb1
10.66.100.0/25 link#28 U bridge3
10.66.100.1 link#28 UHS lo0
127.0.0.1 link#10 UH lo0
172.20.66.0/24 link#26 U bridge1
172.20.66.1 link#26 UHS lo0
172.31.254.0/29 link#29 U bridge0
172.31.254.1 link#29 UHS lo0
192.168.0.0/24 link#2 U igb1
192.168.0.242 link#2 UHS lo0
Internet6:
Destination Gateway Flags Netif Expire
::1 link#10 UHS lo0
fe80::%lo0/64 link#10 U lo0
fe80::1%lo0 link#10 UHS lo0
Thanks a lot for you help and let me know if you need further details
Now out for dogwalk
Cheers
tobi
15
23.7 Legacy Series / auto-generated rules seems to block all traffic?
« on: January 04, 2024, 04:49:01 pm »
Hello and happy new year
I have a weird issue with opnsense 23.7.11 after upgrading from 23.7.7. Although the issue was already present in my new installation of 23.7.7
The issue is: that ALL traffic to the firewall is cut off as soon as the rules are active. Only doing pfctl -d get's me access again. I have an allow any on my LAN interface but it seems that the traffic is shutdown earlier by an auto-generated rule. Namely the one that triggers on port 0 access. Checking the firewall log on local console shows me
that rule 8 seems to have hit "rule 8/0(match)" and if I check the autogenerated rules number 8 is the port 0 rule
is there any way how I can disable this particular rule? Did not find an option in GUI. Furthermore the question is this a bug or an issue on my side? Although I could not imagine a widespread bug as then the forum would be full of such issues
Any hint is highly appreciated
Have a good one
tobi
p.s. seems the embedded screenshots do somehow not work. Need to click on the pic and then after getting to postimg.cc click again to get the pictures in readable
I have a weird issue with opnsense 23.7.11 after upgrading from 23.7.7. Although the issue was already present in my new installation of 23.7.7
The issue is: that ALL traffic to the firewall is cut off as soon as the rules are active. Only doing pfctl -d get's me access again. I have an allow any on my LAN interface but it seems that the traffic is shutdown earlier by an auto-generated rule. Namely the one that triggers on port 0 access. Checking the firewall log on local console shows me
that rule 8 seems to have hit "rule 8/0(match)" and if I check the autogenerated rules number 8 is the port 0 rule
is there any way how I can disable this particular rule? Did not find an option in GUI. Furthermore the question is this a bug or an issue on my side? Although I could not imagine a widespread bug as then the forum would be full of such issues
Any hint is highly appreciated
Have a good one
tobi
p.s. seems the embedded screenshots do somehow not work. Need to click on the pic and then after getting to postimg.cc click again to get the pictures in readable
Pages: [1] 2