Second Lan network same interface
-
Assigning a virtual IP on the LAN interface caused it to lose the global address. There's definitely something wrong with the way pfSense handles ULA.
-
IDK, man. I just did it and it worked fine.
DHCP WAN, Track Interface LAN, ULA IP Alias VIP /64 on LAN, Added ULA /64 as a subnet for RA on LAN, firewall rule passing all traffic from ULA::/64 on LAN, booted test VM:
pfSense LAN:
re0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=80098 <vlan_mtu,vlan_hwtagging,vlan_hwcsum,linkstate>ether fe:e0:54:6e:79:49
hwaddr fe:e0:54:6e:79:49
inet 172.25.233.1 netmask 0xffffff00 broadcast 172.25.233.255
inet6 2001:dead:beef:fd01:fce0:54ff:fe6e:7949 prefixlen 64
inet6 fe80::1:1%re0 prefixlen 64 scopeid 0x1
inet6 fd08:1e26:8fea:525b::1 prefixlen 64
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: activeTest host interface:
derelict@Host-B1:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 9a:b3:de:87:fa:4b
inet addr:172.25.233.100 Bcast:172.25.233.255 Mask:255.255.255.0
inet6 addr: fd08:1e26:8fea:525b:98b3:deff:fe87:fa4b/64 Scope:Global
inet6 addr: fe80::98b3:deff:fe87:fa4b/64 Scope:Link
inet6 addr: 2001:dead:beef:fd01:98b3:deff:fe87:fa4b/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:205 errors:0 dropped:0 overruns:0 frame:0
TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:34081 (34.0 KB) TX bytes:15844 (15.8 KB)To pfSense LAN VIP:
derelict@Host-B1:~$ ping6 -c 3 -I fd08:1e26:8fea:525b:98b3:deff:fe87:fa4b fd08:1e26:8fea:525b::1
PING fd08:1e26:8fea:525b::1(fd08:1e26:8fea:525b::1) from fd08:1e26:8fea:525b:98b3:deff:fe87:fa4b : 56 data bytes
64 bytes from fd08:1e26:8fea:525b::1: icmp_seq=1 ttl=64 time=0.518 ms
64 bytes from fd08:1e26:8fea:525b::1: icmp_seq=2 ttl=64 time=0.294 ms
64 bytes from fd08:1e26:8fea:525b::1: icmp_seq=3 ttl=64 time=0.684 ms–- fd08:1e26:8fea:525b::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.294/0.498/0.684/0.161 msTo the WAN address of upstream pfSense:
derelict@Host-B1:~$ ping6 -c 3 -I fd08:1e26:8fea:525b:98b3:deff:fe87:fa4b 2001:dead:beef:7fff::ed96:eec5
PING 2001:dead:beef:7fff::ed96:eec5(2001:dead:beef:7fff::ed96:eec5) from fd08:1e26:8fea:525b:98b3:deff:fe87:fa4b : 56 data bytes
64 bytes from 2001:dead:beef:7fff::ed96:eec5: icmp_seq=1 ttl=64 time=0.524 ms
64 bytes from 2001:dead:beef:7fff::ed96:eec5: icmp_seq=2 ttl=64 time=0.287 ms
64 bytes from 2001:dead:beef:7fff::ed96:eec5: icmp_seq=3 ttl=64 time=0.320 ms–- 2001:dead:beef:7fff::ed96:eec5 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.287/0.377/0.524/0.104 msI don't have routing for that ULA from anything else.
Note this is a recent 2.4-RC since that's what my test environment is currently running.</full-duplex></performnud,auto_linklocal></vlan_mtu,vlan_hwtagging,vlan_hwcsum,linkstate></up,broadcast,running,simplex,multicast>
-
And with NPt to an unused /64 on pfSense WAN:
derelict@Host-B1:~$ ping6 -n -c 3 -I fd08:1e26:8fea:525b:98b3:deff:fe87:fa4b www.google.com
PING www.google.com(2607:f8b0:400e:c05::63) from fd08:1e26:8fea:525b:98b3:deff:fe87:fa4b : 56 data bytes
64 bytes from 2607:f8b0:400e:c05::63: icmp_seq=1 ttl=46 time=59.6 ms
64 bytes from 2607:f8b0:400e:c05::63: icmp_seq=2 ttl=46 time=83.8 ms
64 bytes from 2607:f8b0:400e:c05::63: icmp_seq=3 ttl=46 time=58.7 ms–- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 58.704/67.398/83.847/11.640 ms -
I'll have to go through the stuff you provided, howerver I made some changes and did some more testing. At the moment, the configuration is as follows:
LAN global & ULA
LAN4 ULA only
VLAN3 ULA onlyThe desktop computer has both LAN and VLAN3 configured and the notebook is on LAN4 only.
If I ping the laptop by forcing ping over VLAN3, it works. However, when via LAN, no response. Wireshark on the notebook shows both request and reply, but on the desktop, only the request. From the pfSense computer, I can ping the notebook and the VLAN3 address of the desktop, but not the LAN address. Wireshark does not show any ping requests from pfSense to the LAN interface So, there is still something about the LAN interface that's causing problems.
I see you have a ULA address fd08:1e26:8fea:525b::1 on the LAN interface. How did you put it there? I do not have one. I used a virtual IP last night, but this morning, the virtual IP was there, but the global address was gone.
The network ULA addresses are as follows:
LAN fd48:1a37:2160:0::
VLAN3 fd48:1a37:2160:3::
LAN4 fd48:1a37:2160:4::Netstat -r on pfSense shows:
fd48:1a37:2160:3:: link#8 U bge0_vla
fd48:1a37:2160:3:: link#8 UHS lo0
fd48:1a37:2160:4:: link#2 U em0
fd48:1a37:2160:4:: link#2 UHS lo0Note there is no line for fd48:1a37:2160:0::.
There is also this on the WAN interface:
fd07:f798:3:16e:: link#3 U re0
fd07:f798:3:4172:: link#3 U re0There are no other ULA addresses listed. So, pfSense doesn't have a route to fd48:1a37:2160:0::.
-
I think I found it. I had to set the VIP prefix to /64. Also, curious that the pfSense graphical admin doesn't show the 2nd address on either the dashboard or interface status. Netstat -r does though.
-
"I had to set the VIP prefix to /64"
what else would you have set it too?
-
The default is /128, so if you forget to change it…
Now I can add gazillions of security cameras to that network! ;)
-
I just tried pinging ipv6.google.com from a computer with a ULA and I see the requests heading out of the WAN port. I guess I should create a rule to block ULA addresses.
-
Yup. Just like RFC1918.
-
I just created a floating rule to block fc::/7 in both directions, but the pings are still leaving the firewall.
-
Did you kill the existing states?
Or at least stop and restart the ping?
-
You should also check quick there.
-
I did try it and it didn't make any difference. I'm using Wireshark, to monitor the cable from the firewall to cable modem. I just set it again and it's still not blocking.
-
Well, that virtual IP killed my network again. I had to remove it for things to work properly.
-
IDK again, man. Works here…
Packet capture on WAN for fc00::/7 shows nothing as well.
![Screen Shot 2017-09-08 at 3.21.53 PM.png](/public/imported_attachments/1/Screen Shot 2017-09-08 at 3.21.53 PM.png)
![Screen Shot 2017-09-08 at 3.21.53 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2017-09-08 at 3.21.53 PM.png_thumb) -
I have absolutely no idea what's causing these problems. I'm running the latest version on a refurb computer.
-
Everything I am doing is 2.4-RC on a XenServer VM. I have no reason to believe 2.3.4_1 on a physical would be any different.