Solved Cloned loopback that cannot be pinged.

Like in a title I did cloned loopback lo1 but I am not able to ping it.

cloned_interfaces="tun lo1 lo2"


Code:
#ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo
lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.1.1 netmask 0xffffffff
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: lo

Code:
# ping 127.0.1.1
PING 127.0.1.1 (127.0.1.1): 56 data bytes
ping: sendto: Permission denied
ping: sendto: Permission denied
^C
--- 127.0.1.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.066 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.040 ms
^C
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.040/0.053/0.066/0.013 ms

added to pf.conf:
Code:
set skip on lo1

Code:
#sysctl -a | grep securelevel
kern.securelevel: -1
security.jail.param.securelevel: 0

Code:
 # uname -a
FreeBSD karo 11.2-RELEASE-p9 FreeBSD 11.2-RELEASE-p9 #0: Tue Feb  5 15:30:36 UTC 2019     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
Any idea how to proceed to fix this?
 
set skip on lo0 doesn't include lo1 or lo2, or any other lo* interface besides lo0. For all intents and purposes a cloned interface is a new and separate interface.

Code:
     set skip on <ifspec>
           List interfaces for which packets should not be filtered.  Packets
           passing in or out on such interfaces are passed as if pf was
           disabled, i.e. pf does not process them in any way.  This can be
           useful on loopback and other virtual interfaces, when packet
           filtering is not desired and can have unexpected effects.  For
           example:

                 set skip on lo0
 
Thanks, Yeah I fixed that. set skip on lo1 then pfctl -f /etc/pf.conf then restarted the server just in case...
then did try pass on lo1 all and still, I am getting 'Permission denied', any other place where cloned interface might be blocked? Or is it done by design?
 
Is this inside a jail or on a "plain" host?

Code:
root@hosaka:~ # ifconfig lo1
ifconfig: interface lo1 does not exist
root@hosaka:~ # ifconfig lo1 create
root@hosaka:~ # ifconfig lo1 inet 127.0.1.1 netmask 255.255.255.255
root@hosaka:~ # ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
root@hosaka:~ # ifconfig lo1
lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.1.1 netmask 0xffffffff
        groups: lo
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@hosaka:~ # ping -c 4 127.0.1.1
PING 127.0.1.1 (127.0.1.1): 56 data bytes
64 bytes from 127.0.1.1: icmp_seq=0 ttl=64 time=0.040 ms
64 bytes from 127.0.1.1: icmp_seq=1 ttl=64 time=0.048 ms
64 bytes from 127.0.1.1: icmp_seq=2 ttl=64 time=0.057 ms
64 bytes from 127.0.1.1: icmp_seq=3 ttl=64 time=0.042 ms

--- 127.0.1.1 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.040/0.047/0.057/0.007 ms
Did nothing special, just created the interface and assigned an IP address to it. No firewall on this machine though.
 
This is in the plain host. I have PF enabled so the problem must be here.

Code:
root@karo:~ # ifconfig lo3
ifconfig: interface lo3 does not exist
root@karo:~ # ifconfig lo3 create
root@karo:~ # ifconfig lo3 inet 127.0.1.3 netmask 255.255.255.255
root@karo:~ # ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo
root@karo:~ # ifconfig lo3
lo3: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.1.3 netmask 0xffffffff
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: lo
root@karo:~ # ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.021 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.021/0.021/0.021/0.000 ms
root@karo:~ # ping -c 1 127.0.1.3
PING 127.0.1.3 (127.0.1.3): 56 data bytes
ping: sendto: Permission denied
^C
--- 127.0.1.3 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
 
I have PF enabled so the problem must be here.
Easy enough to test, just disable it temporarily; pfctl -d. You can enable it again with pfctl -e.

Can you post your pf.conf?
 
I did disabled it. Still the same result. So PF is eliminated. Maybe some kernel settings?
 
both disabled enabled - still can not ping. server restarted. the second server is working fine. but as they are old I cannot find a difference.
 
You wrote "disabled enabled". Try just disabling and then ping again.
The "permission denied" message suggests strongly that its because of the firewall.
  1. firewall down.
  2. try to ping.

Also, if your firewall rules do logging, you should be able to see Denied packets in /var/log/security. If your rules don't log, just add logging to all rules that Deny stuff. Then you'll see exactly which rule stopped the packets.
 
Correct that was a firewall IPFW. I did not disable it properly in the first place and I got the wrong message. All is working as it should now. Thank you, guys.
 
I am glad that you understood your problem. For the protocol, IPFW can be disabled like so: service ipfw stop
Logging can be enabled by sysrc firewall_logging="YES" and making sure the deny rules have a log keyword. For example:
${ipfw} add deny log ip from 224.0.0.0/4 to any out via ${ExternalInterface}
 
Back
Top