Topics

Hello forum

we're currently facing a weird Wireguard problem which makes 0 sense to me. We have

server side 10.20.60.0/24 server side wg IP 10.230.0.1 and server side opnsense local IP 10.20.60.2

Code Select Expand

peer: jv41jYNdMIt+OGZcgBFBjNJxYeZasPHOTm6axu1lWzw=
  endpoint: redacted:60554
  allowed ips: 10.3.0.0/16, 10.230.0.254/32
  latest handshake: 53 seconds ago
  transfer: 44.95 GiB received, 20.35 GiB sent
  persistent keepalive: every 30 seconds

client side 10.3.0.0/16 client side wg IP 10.230.0.254 and client side opnsense local IP 10.3.0.5

Code Select Expand

peer: 56tUzFXZ1QrweRqKCyJyG1OPeKYv0Fr9Ke/sBA/viR0=
  endpoint: redacted:51820
  allowed ips: 10.20.50.0/24, 10.11.0.0/16, 10.20.60.0/24, 10.231.0.0/16, 10.230.0.1/32
  latest handshake: 1 minute, 59 seconds ago
  transfer: 19.33 GiB received, 45.48 GiB sent
  persistent keepalive: every 30 seconds

peer config on both sides allow the remote local net traffic

When I try to ping from 10.20.60.8 to 10.3.0.81 I can see on the firewall that the traffic comes in on LAN interface but is not shown on wg1 interface. Also not shown outgoing on ANY other interface. Route on the firewall (server side) looks okay

Code Select Expand

route -n get 10.3.0.81
   route to: 10.3.0.81
destination: 10.3.0.0
       mask: 255.255.0.0
        fib: 0
  interface: wg1
      flags: <UP,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1420         1         0
Also the firewall itself can ping the 10.3.0.0/16 subnet. There are NO firewall rules that would block the traffic. The firewall itself can reach the remote network without issues. Also the remote network (client side) can reach the local network (server side). Also when I ping from 10.20.60.8 to the Wireguard IP of the remote firewall (10.230.0.254) I get replies. But not if I ping the local IP of the remote firewall (10.3.0.5). We do not use outgoing NAT rules as the remote systems have routes for the local net via their local opnsense. But for testing I tried with an explicit outgoing NAT rule but no success either.

Are we hitting a bug? I tried to debug the issue for quite a while now, but we absolutely no success. The fact that I cannot see traffic leaving on server side wg1 interface indicates to me that the packets are either misrouted (although I cannot see the outgoing traffic on any interface) or dropped (although even with pfctl -d it does not work)

Any ideas?

Kind regards

tobi

Also this firewall has WG connections to many other endpoints and there is no problem in reaching those remote networks. It's just this 10.3.0.0/16 destination network that causes trouble

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

Code Select Expand


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

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

Code Select Expand

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 bridge0

but no bindings to the two ports according to netstat command

Code Select Expand


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

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 :)

Hello

running latest  OPNsense 22.7_4-amd64 and having an issue with routing via a openvpn connection. I setup openvpn server on opnsense and added the remote network in question (192.168.77.0/24) to server settings in "IPv4 Remote Networks" and to the correct "Client specific overwrite". When the client connects to the server I can see that the route is learned to main routing table.

Code Select Expand


root@OPNsense:~ # route -n get 192.168.77.130
   route to: 192.168.77.130
destination: 192.168.77.0
       mask: 255.255.255.0
    gateway: 10.230.0.2
        fib: 0
  interface: ovpns2
      flags: <UP,GATEWAY,DONE,STATIC>
recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

10.230.0.2 is the vpn ip of the correct client. I can ping it. But if I try to ping an ip in 192.168.77.0/24 there is no response. If I tcpdump on the client I cannot see one paket coming in on the openvpn connection.
If I check the routing table on server in VPN > connection Status > Routing table I cannot see the route for that network.

From what I know from other openvpn on other opnsense boxes there should be the route to that network displayed. So it seems to me that openvpn does not learn the route internally.

any idea how I could solve this / why the route is not displayed in connection status page?
If more details are needed I'm happily provide it on request :-)

Thanks for any hint

Cheers

tobi