Messages

1

24.7 Production Series / Re: How to allowlist outgoing traffic from IPv6 static privacy (RFC7217) addresses

« on: October 29, 2024, 03:46:49 pm »

Place hosts that share an outbound policy in a common network/VLAN and ignore host addresses. Filtering by address does not scale and is easily spoofed.

This seems to be the most straightforward way, thanks for confirming.

2

24.7 Production Series / Re: How to allowlist outgoing traffic from IPv6 static privacy (RFC7217) addresses

« on: October 29, 2024, 03:42:16 pm »

Also, please do not use /57 as LAN networks, you must (almost) always use /64 for IPv6 networks.

My bad, it was late at night when I posted. I have a number of /64s in the /57 that's been delegated to my OPNsense router by my CPE router (that has the /48).

3

24.7 Production Series / How to allowlist outgoing traffic from IPv6 static privacy (RFC7217) addresses

« on: October 28, 2024, 11:14:23 pm »

Hi,

I am migrating to IPv6 only. I have a /48 from my ISP which I have created a number of /57 local prefixes in which I am hosting various vms and physical machines.

All these hosts I have set to use SOII (the OpenBSD name for RFC7217 addresses). In short each host has a static listening address and fairly rapidly cycles through random(?) addresses in the /57 for outgoing traffic. I think Windows hosts do something similar so what I am asking here is I guess a fairly common use case.

Any incoming traffic through OPNsense is easy to add to allowlists in firewall rules as the addresses is static, but the outgoing traffic is causing me issues.

I would like to, on a host-by-host basis create allowlists and so firewall rules for specific outgoing traffic. So far I have tried allowing by src MAC address (even though it was in an "IPv6" rule); this worked for a while but then started blocking the traffic some hours later*. I have settled on allowing the entire /57 (I basically have a single host in each /57 I have created so far) but this seems unsatisfactory and not a long term solution.

Does anyone have any advice/war stories regarding the same? I thought I'd check here before I head upstream.

*I had a quick read around and filtering by MAC does seem a bad idea:
- Still true?: https://forum.opnsense.org/index.php?topic=2790.0
- Also seems like it could get bad performance: https://forums.freebsd.org/threads/filtering-by-mac-address.32841/

4

18.7 Legacy Series / Should unbound plugin break dhcp-provided dns nameserver on _all_ my subnets?

« on: December 17, 2018, 10:24:01 pm »

Hi,

I have dhcp active on all my subnets. This works well and provides the dns nameserver option for my dhcp clients to point to a couple of non-opnsense nameservers I use internally.

I am now configuring unbound to listen on just a single vlan/subnet.

I spotted this at the bottom of the plugin config page:

If the DNS Resolver is enabled, the DHCP service (if enabled) will automatically serve the LAN IP address as a DNS server to DHCP clients so they will use the DNS Resolver.

This is a pity because it doesn't just provide the nameservers for the vlan I'm targeting (also through ipv6 RAs, not just dhcp as mentioned in the quote) but it overrides my custom dhcp dns nameserver settings for _all_ other scopes.

Is this really necessary? Is it possible to change this behaviour?

Thanks

5

18.7 Legacy Series / squid config generator having problems with ipv6 address

« on: December 17, 2018, 10:17:09 pm »

Hi,

I have ipv6 working well (I believe). I get a prefix on my opnsense host from my ISP (XS4ALL) and distribute it to downstream ipv6-only vlans using radvd.

I am trying to set up a non-transparent (opaque?) proxy in each of these vlans using the built-in squid proxy from opnsense. Here I have a problem.

I set the proxy to use the ipv6-only vlan interface as a "Proxy interface" but the squid.conf doesn't get generated correctly. I get:

Code: [Select]

# grep -E 'https_port|http_port' /usr/local/etc/squid/squid.conf
http_port 127.0.0.1:3128 intercept
http_port [::1]:3128 intercept
http_port 192.168.1.10:3128 
http_port 10.1.8.1:3128 
http_port 10.1.9.1:3128 
http_port 10.1.6.1:3128 
http_port 10.1.2.1:3128 
http_port 10.1.4.1:3128
http_port :3128   <--- problem line
http_port 10.1.5.1:3128 
You'll see some other ipv4-only vlan interface addresses there.

My ipv6-only vlan interface looks like this:

Code: [Select]

# ifconfig lagg0_vlan640
lagg0_vlan640: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:02:b0:1a:68:39
inet6 2001:dead:beef:a8:202:b0ff:fe1a:6839 prefixlen 64
inet6 fe80::1:1%lagg0_vlan640 prefixlen 64 scopeid 0x14
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: active
vlan: 640 vlanpcp: 0 parent interface: lagg0
groups: vlan

If I put that address in the squid.conf replacing the 'problem line' above it seems to work correctly, clients in that vlan can use the proxy just fine:

Code: [Select]

# netstat -an|grep 3128
tcp4       0      0 10.1.2.1.3128          10.1.2.23.33264        ESTABLISHED
tcp4       0      0 10.1.5.1.3128          *.*                    LISTEN
tcp6       0      0 2001:dead:beef:a8.3128 *.*                    LISTEN
tcp4       0      0 10.1.4.1.3128          *.*                    LISTEN
tcp4       0      0 10.1.2.1.3128          *.*                    LISTEN
tcp4       0      0 10.1.6.1.3128          *.*                    LISTEN
tcp4       0      0 10.1.9.1.3128          *.*                    LISTEN
tcp4       0      0 10.1.8.1.3128          *.*                    LISTEN
tcp4       0      0 192.168.1.10.3128      *.*                    LISTEN
tcp6       0      0 ::1.3128               *.*                    LISTEN
tcp4       0      0 127.0.0.1.3128         *.*                    LISTEN

Could it be that the squid.conf generator just isn't inserting that address correctly? I use the unbound plugin too and it puts that ipv6 address in its config file just fine.

Thanks

6

18.1 Legacy Series / Re: No IPv6 prefixes between 56 and 60 allowed?

« on: March 20, 2018, 09:26:46 am »

Excellent, looks like it will soon be all sorted. I will just make a bug report next time.

As you say, I had selected Basic with a prefix of /60 before I chose the Config File Override, so yes, I only got the choice of 0 to f. Selecting Basic and /56 and applying it prior to selecting Config File Override allowed me to "Enter a hexadecimal value between 0 and ff here," for the prefix id in the track interface section.

Thanks for the quick response.

7

18.1 Legacy Series / No IPv6 prefixes between 56 and 60 allowed?

« on: March 19, 2018, 10:17:11 pm »

Hi,

I'm successfully running a a wan interface with a DHCPv6 Config File Override that gets a /57 prefix from an upstream router and configures some internal vlan interfaces.

This works nicely.

My override file, /var/etc/dhcp6c_wan.override.conf looks like this:

Code: [Select]

interface igb3 {
  send ia-na 0; # request stateful address
  send ia-pd 0; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 0 { };
id-assoc pd 0 {
  prefix ::/57 infinity;
  prefix-interface lagg0_vlan620 {
    sla-id 20;
    sla-len 7;
  };
  prefix-interface lagg0_vlan640 {
    sla-id 40;
    sla-len 7;
  };
  prefix-interface lagg0_vlan660 {
    sla-id 60;
    sla-len 7;
  };
  prefix-interface lagg0_vlan680 {
    sla-id 80;
    sla-len 7;
  };
};
This is basically an extension from what gets created from the "Basic" mode, only I have:
1. A /57 prefix. My upstream router gets a /48 from my ISP but then will only hand out a /57 and no other. This 57 is not a chooseable option in the "Basic" interface, it goes from 56 to 60. Can this be fixed?
2. sla-ids that are more than 0xf, which is the maximum "allowed" in the "Track Interface" part of each interface's config. Can this be fixed too?

Thanks,
Ben

8

17.7 Legacy Series / Re: Seemingly uncalled-for resets while port forwarding

« on: November 04, 2017, 10:00:45 pm »

So, I gave up and used the HAProxy plugin instead. Nice to have learned something new.

9

17.7 Legacy Series / Seemingly uncalled-for resets while port forwarding

« on: October 30, 2017, 08:18:37 pm »

Hi,

I'm having an intermittent problem with (I think) my Opnsense 17.7.7 router/firewall. Apologies up front if I've missed some other post describing exactly this problem.

So, I have this Opnsense firewall (192.168.178.20) and a rpi3 (192.168.178.21) sitting on my flat network behind my ISP's CPE (192.168.178.1). I then have my real home network behind the Opnsense firewall.

I'm trying to terminal a little bit of HTTPS traffic from the outside world on the rpi3 and send it through my firewall as plain HTTP via a port forward from 192.168.178.20:1644/tcp to my Nextcloud server (10.1.6.44:80/tcp) in my real home network.

This works half the time. I'll show you what I mean.

Here's a successful wget from my docker instance on the rpi3:

Code: [Select]

root@b3f74cc5c974:/$ wget --header 'Host: myserver.com' http://192.168.178.20:1644/blah1.php
Connecting to 192.168.178.20:1644 (192.168.178.20:1644)
wget: server returned error: HTTP/1.1 404 Not Found
root@b3f74cc5c974:/$ netstat -tupa
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 localhost:9000          0.0.0.0:*               LISTEN      313/php-fpm.conf)
tcp        0      0 0.0.0.0:11211           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:http            0.0.0.0:*               LISTEN      309/nginx.conf
tcp        0      0 0.0.0.0:https           0.0.0.0:*               LISTEN      309/nginx.conf
tcp        0      0 b3f74cc5c974:37972      myopnsensebox.com:1644  TIME_WAIT   -
tcp        0      0 :::11211                :::*                    LISTEN      -
udp        0      0 0.0.0.0:11211           0.0.0.0:*                           -
udp        0      0 :::11211                :::*                                -
And the Nextcloud server's access.log:

Code: [Select]

myserver.com 192.168.178.21 - - [30/Oct/2017:19:46:43 +0100] "GET /blah1.php HTTP/1.1" 404 0
So, the page isn't there, but they're at least they're on speaking terms.

Weird thing is that just a few seconds later I try again and get this:

Code: [Select]

root@b3f74cc5c974:/$ wget --header 'Host: myserver.com' http://192.168.178.20:1644/blah2.php
Connecting to 192.168.178.20:1644 (192.168.178.20:1644)
wget: can't connect to remote host (192.168.178.20): Connection refused
What's happening?

I did a traffic capture on the outside (192.168.178.20) and inside (10.1.6.1) interfaces of the firewall (simple text captures attached), but the crux of it is that the outside interface is resetting the second connection immediately like so:

Code: [Select]

19:47:40.630906 IP 192.168.178.21.37974 > 192.168.178.20.1644: Flags [S], seq 4153658341, win 29200, options [mss 1460,sackOK,TS val 10306995 ecr 0,nop,wscale 7], length 0
19:47:40.631670 IP 192.168.178.20.1644 > 192.168.178.21.37974: Flags [R.], seq 0, ack 4153658342, win 0, length 0
This is not showing up in any logs I can see, where can I look for what is doing this??

Many thanks,
Ben

10

16.7 Legacy Series / Re: VLAN traffic going missing on bridge interface

« on: November 12, 2016, 06:29:26 pm »

Hi Franco,

I will look into it further when I can, but I think for now I will give in and buy a managed switch and do the plumbing downstream of my opnsense host.

I'm guessing there is no analogue of a Cisco BVI for opnsense/freebsd because bridging vlans on 2 physical interfaces (say igb1_vlan1016 and igb2_vlan1016) will get the kernel involved in layer 2 switching and that will never be very nice unless there's some hardware integration like on Cisco (and other) devices. Right?

Still, it's something that would be nice to have working in the end.

Many thanks for your time.

11

16.7 Legacy Series / Re: VLAN traffic going missing on bridge interface

« on: November 11, 2016, 05:55:18 pm »

Hi, I wonder if there are any further thoughts from anyone about this one.

Just to summarize, my problems are like so:

Code: [Select]

physical = fine
physical ---> vlan = fine
physical ---> bridge = fine
physical -|-> vlan ---> bridge = not fine
In that everything works apart from certain traffic going missing (at least according to tcpdump) between physical and vlan interfaces in the last configuration. I say 'going missing' instead of 'being dropped' as I can't find any trace of missing packets with netstat, ifconfig, pf logs or any other tools I can think of.

This testing is all done on a single physical interface (although the whole point is to incorporate others).

I turned off all hardware offloards (vlanhwfilter etc.) without luck.

Where can I look for documentation/hints to go forward?

Worth trying the same setup in pfsense or vanilla freebsd to see if I can recreate it?

Thanks

12

16.7 Legacy Series / Re: VLAN traffic going missing on bridge interface

« on: November 04, 2016, 01:24:53 pm »

I thought I would also try for fun to take the vlans out of the question, and the bridged interface does indeed work correctly with a device plugged into igb2.

Code: [Select]

bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:7e:e3:17:05:00
inet 10.1.6.1 netmask 0xffffff00 broadcast 10.1.6.255
nd6 options=1<PERFORMNUD>
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: igb2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        ifmaxaddr 0 port 3 priority 128 path cost 55

13

16.7 Legacy Series / Re: VLAN traffic going missing on bridge interface

« on: November 04, 2016, 12:47:27 pm »

Ok, I have given it a go.

Unfortunately my packet captures are pretty much the same, with all the traffic from the host sitting on vlan1016 hitting igb1 but getting no further. As before traffic out to the host (an icmp ping) reaches the host, and the host replies, but again, that traffic gets lost somewhere after it hits igb1.

I am pretty sure the firewall is not to blame here (although my pf-log-reading-fu might need some sharpening). Default drop rule logging is enabled and I have no other drop rules.

I also tried setting the bridge sysctl parameters back to 'default' but still the same.

Am I conceptually doing something wrong by setting up these bridges as my only addressed interfaces (apart from WAN and LAN)?

14

16.7 Legacy Series / Re: VLAN traffic going missing on bridge interface

« on: October 31, 2016, 10:23:15 pm »

Sorry, vga thanks.

15

16.7 Legacy Series / Re: VLAN traffic going missing on bridge interface

« on: October 31, 2016, 10:26:32 am »

Hi Franco,

I would be more than happy to try out a USB image with my config.

Cheers