Adding a multicast route to an interface in OSX - macos

I have a VM running in Fusion that I want to hit by routing a specific endpoint address through the virtual ethernet interface (multicast DNS, in particular). First I was sending packets and inspecting with Wireshark noticing that nothing was getting through. Then I thought to check the routing table
$ netstat -rn | grep vmnet8
Destination Gateway Flags Refs Use Netif Expire
172.16.12/24 link#29 UC 2 0 vmnet8 !
172.16.12.255 ff:ff:ff:ff:ff:ff UHLWbI 0 35 vmnet8 !
But unlike other interfaces,
Destination Gateway Flags Refs Use Netif Expire
224.0.0.251 a1:10:5e:50:0:fb UHmLWI 0 732 en0
224.0.0.251 a1:10:5e:50:0:fb UHmLWI 0 0 en8
There was no multicast route. So I added it:
$ sudo route add -host 224.0.0.251 -interface vmnet8
add host 224.0.0.251: gateway vmnet8
And so it was true
$ netstat -rn | grep vmnet8
Destination Gateway Flags Refs Use Netif Expire
172.16.12/24 link#29 UC 2 0 vmnet8 !
172.16.12.255 ff:ff:ff:ff:ff:ff UHLWbI 0 35 vmnet8 !
224.0.0.251 a1:10:5e:50:0:fb UHmLS 0 13 vmnet8
I was also sure to check the interface flags to ensure it had been configured to support multicast
$ ifconfig vmnet8
vmnet8: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
ether 00:70:61:c0:11:08
inet 172.16.12.1 netmask 0xffffff00 broadcast 172.16.12.255
Still, no multicast packets I send are getting through. I noted that the other interface's multicast route have different flags than the default ones given to my added route. Namely UHmLWI vs UHmLS. The differences I can see are insignificant. From man netstat:
I RTF_IFSCOPE Route is associated with an interface scope
S RTF_STATIC Manually added
W RTF_WASCLONED Route was generated as a result of cloning
Then again, I'm not claiming to be a routing expert. Perhaps a multicast route entry must be made somehow differently?
You'll note that the Use column is non-zero, despite no packets showing in a sniffer.

Related

Why can't I configure a static ip on raspberry pi?

I am trying to add a static ip address on raspberry-pi and can't get it working...
ifconfig on pi
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.68.104 netmask 255.255.255.0 broadcast 192.168.68.255
inet6 fe80::1e8e:49a0:5bf:ad41 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:c4:41:05 txqueuelen 1000 (Ethernet)
RX packets 210 bytes 49138 (47.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 189 bytes 28376 (27.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
gateway
192.168.xx.x
/etc/resolv.conf:
nameserver 62.179.104.xxx
nameserver 213.46.228.xxx
dhcpcd.conf settings:
interface wlan0
static ip_address=192.168.68.68/20
static routers=192.168.xx.x
static domain_name_servers=62.179.104.xxx 213.46.228.xxx
I have also tried static ip_address=192.168.68.68/24
reboot pi and hostname -I it still gives me the origin ip: 192.168.68.104
What am I doing wrong here? or Is there another way to set a static ip on raspberry pi?
First of all make sure the dhcpcd service is enabled and running:
sudo service dhcpcd status
If that is not the case:
sudo service dhcpcd start
sudo systemctl enable dhcpcd
Now you can edit the dhcpcd config (like you already did)
sudo nano /etc/dhcpcd.conf
If you have a network cable use: eth0 and on wifi: wlan (not wlan0)
interface eth0
static ip_address=192.168.0.4/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1
Configure this like you need.
After this reboot.
Good luck!

How to disable and enable internet connection from within Docker container?

I am clearing /etc/resolv.conf to disable network :
sudo mv /etc/resolv.conf /etc/resolv_backup.conf
sudo touch /etc/resolv.conf
Then to enable network:
sudo mv /etc/resolv_backup.conf /etc/resolv.conf
However the resource is busy and I cannot execute these commands.
I want to disable internet from within container and not using:
docker network disconnect [OPTIONS] NETWORK CONTAINER
which does this from server on which container is deployed.
I am using Alpine.
From inside of a container, you are typically forbidden from changing the state of the network:
$ docker run -it --rm alpine:latest /bin/sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
929: eth0#if930: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
/ # ip link set eth0 down
ip: ioctl 0x8914 failed: Operation not permitted
This is intentional, for security, to prevent applications from escaping the container sandbox. If you do not need security for your containers (and therefore something I recommend against doing), you can run your container with additional network capabilities:
$ docker run -it --rm --cap-add NET_ADMIN alpine:latest /bin/sh
/ # netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 172.17.0.1 0.0.0.0 UG 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
933: eth0#if934: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
/ # ip link set eth0 down
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable
When you try to bring the network back up, you'll need to also setup the default route again to be able to connect to external networks:
/ # ip link set eth0 up
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable
/ # netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
/ # route add default gw 172.17.0.1
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=58 time=12.518 ms
64 bytes from 8.8.8.8: seq=1 ttl=58 time=11.481 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 11.481/11.999/12.518 ms
First of all, clearing resolv.conf is not the proper way to disable network for your container. That just avoids name resolution, but you still can use IP connectivity.
To disable the network you should use the proper script depending if you are using systemd or sysV. Something similar to this should work (it depends on your distro):
# /etc/init.d/networking stop
# systemctl stop networking
Hope this helps! :-)

can we change default gateway and interface in mac through commandline

We can see default gateway and interface of MAC by using following command
route -n get default
I know that this is possible in linux
and can be achieved by following commands
route change default -interface $INTF
route change 192.168.0.0/16 -interface $INTF
But these are not working in MAC. My objective is to change the Default Gateway and interface.
The networksetup utility should be able to do what you want.
For example, to manually set up the standard Ethernet interface with an IP of 192.168.100.100, subnet of 255.255.255.0 and gateway of 192.168.100.1:
networksetup -setmanual "Ethernet" 192.168.100.100 255.255.255.0 192.168.100.1
You might also be interested in the -setadditionalroutes flag.
I recently had an instance where someone setup dual default routes
grant#dd08-mac:~[20220909-15:59][#8625]% netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 10.17.124.1 UGScg en0
default 10.1.78.1 UGScIg bridge0
10.1.78/24 link#16 UCS bridge0 !
10.1.78.1/32 link#16 UCS bridge0 !
10.1.78.1 link#16 UHLWIir bridge0 !
10.1.78.24 link#16 UHLWI bridge0 !
10.1.78.58/32 link#16 UCS bridge0 !
10.1.78.58 36.6a.e9.47.a5.80 UHLWIi lo0
10.1.78.255 ff.ff.ff.ff.ff.ff UHLWbI bridge0 !
-snip-
I reset the interface with networksetup - this deleted the extra route
grant#dd08-mac:~[20220909-16:04][#8885]% sudo networksetup -setmanual Ethernet 10.17.124.78 255.255.255.0 0.0.0.0
Password:
grant#dd08-mac:~[20220909-16:11][#8924]
and the extra route is gone
grant#dd08-mac:~[20220909-16:11][#8964]% netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 10.1.78.1 UGScg bridge0
10.1.78/24 link#16 UCS bridge0 !
10.1.78.1/32 link#16 UCS bridge0 !
10.1.78.1 link#16 UHRLWIir bridge0 19
10.1.78.58/32 link#16 UCS bridge0 !
10.1.78.58 36.6a.e9.47.a5.80 UHLWIi lo0
10.17.124/24 link#9 UCS en0 !
10.17.124.5 0:25:90:55:6d:e3 UHLWIi en0 1191
10.17.124.78/32 link#9 UCS en0 !
-snip-

How to enable routing in OS X El Capitan

I've got a Linux VMware virtual machine (guest) configured with a NAT adapter on a 192.168.56.0 subnet. Its IP address is 192.168.56.128 and my Mac (host) got 192.168.56.1. Guest's default gateway is automatically set to 192.168.56.2 and is able to ping google. Host's Wi-Fi IP is 192.168.0.2,
I've configured my Wi-Fi router with following routing table to forward packets of 192.168.56.0 to 192.168.0.2 (my Mac)
pi#raspberrypi ~ $ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.4.1 0.0.0.0 UG 0 0 0 eth0
172.16.4.0 * 255.255.252.0 U 0 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 wlan0
192.168.56.0 192.168.0.2 255.255.255.255 UGH 0 0 0 wlan0
192.168.57.0 192.168.0.2 255.255.255.255 UGH 0 0 0 wlan0
But I'm unable to ping guest from any other device on the Wi-Fi network (192.168.0.0). So it's obvious that my Mac running OS X El Capitan is not forwarding the packets from 192.168.0.0 to 192.168.56.0
Not sure about your specific case. In my case I just had two ethernets on the same MacMini and one host being one of these ethernets. The only thing I had to do is sudo sysctl -w net.inet.ip.forwarding=1
https://roelant.net/2015/share-your-vpn-mac-el-capitan.html however noted another variable as well (sudo sysctl -w net.inet.ip.fw.enable=1) and went into a NAT scenario (which I did not need)

Add route in VPN connection Mac OS X

I have following routing table:
➜ ~ netstat -nr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 63 1 en0
default 10.255.254.1 UGScI 1 0 ppp0
10 ppp0 USc 2 4 ppp0
10.255.254.1 10.255.254.2 UHr 1 0 ppp0
92.46.122.12 192.168.0.1 UGHS 0 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 2 62144 lo0
169.254 link#4 UCS 0 0 en0
192.168.0 link#4 UCS 8 0 en0
192.168.0.1 c0:4a:0:2d:18:48 UHLWIir 60 370 en0 974
192.168.0.100 a0:f3:c1:22:1d:6e UHLWIi 1 228 en0 1174
How can I add gateway(10.25.1.252) to specific IP(10.12.254.9) inside VPN.
I tried this command but with no luck:
sudo route -n add 10.12.0.0/16 10.25.1.252
But traceroute show that it uses default gateway:
~ traceroute 10.12.254.9
traceroute to 10.12.254.9 (10.12.254.9), 64 hops max, 52 byte packets
1 10.255.254.1 (10.255.254.1) 41.104 ms 203.766 ms 203.221 ms
Are you using Cisco AnyConnect? Here's a tidbit from https://supportforums.cisco.com/document/7651/anyconnect-vpn-client-faq
Q. How does the AnyConnect client enforce/monitor the
tunnel/split-tunnel policy?
A. AnyConnect enforces the tunnel policy in 2 ways:
1)Route monitoring and repair (e.g. if you change the route table),
AnyConnect will restore it to what was provisioned.
2)Filtering (on platforms that support filter engines). Filtering ensures that even if you could perform some sort of route injection, the filters would block the packets.
Which I interpret as: Whenever you change the route from, the Cisco client resets the route to what your VPN administrator configured.
Your best bet it to talk to you VPN administrator and ask them to add your route.

Resources