I have two machines, vm1, vm2, with tailscale installed on both.
each machine is running lxd with containers.
each machine has its own private subnet, 10.55.1.0/24 and 10.55.5.0/24 respectively.
Tailscale is setup to advertise routes, so that containers on either vm1 or vm2 can talk to each other.
Containers on either vm1 or vm2 can ping other containers on the other host, tcp and udp is working fine.
The problem is that once the packets jump through the tailscale tunnel, they lose their source ip but instead have the
ip address of the tailscale0 address of the machine from which they originated.
i.e. container1 (with address 10.55.1.20) pings container2 on vm2 (with address 10.55.5.20).
When the packet arrives on vm2, it looks like its from vm1 (100.64.x.x) instead of 10.55.1.20)
I can not seem to find the right combination of tailscale up flags for tailscale not to nat the source address.
--snat-subnet-routes=false looks like the right flag to be used, but I can't see any difference in my testing.
vm1 tailscale up command:
tailscale up --accept-routes --accept-dns=false --advertise-routes=10.55.5.0/24 --snat-subnet-routes=false
vm2 tailscale up command is the same other than the advertised subnet.
What I want to see:
on container2, any packets from container1 should have a source address 10.55.1.20, rather than 100.64.x.x of vm1.
vm1 and vm2 are debian linux boxes, and are running latest tailscale client (1.26.1)
I tried setting up a bridge with tailscale0 as outlined here:
Bridged interfaces and Tailscale "Raspberry"
but not have had any success - but that could be a different question.
Related
I installed a vbox in ubuntu 18.04, and used bridged network by adding parameters:
--bridgeadapter2 eno1 --nicpromisc2 allow-all
Everything goes fine, vm can ping outside, and host can ping vm, but outside can not ping vm:
(outside in the same subnet can ping vm, for example: 10.124.214.x can ping vm)
# 10.124.214.116 is vm, 10.124.214.4 is host, 10.124.12.103 is outside IP
# From host to vm
traceroute 10.124.214.116
traceroute to 10.124.214.116 (10.124.214.116), 30 hops max, 60 byte packets
1 10.124.214.116 (10.124.214.116) 0.232 ms 0.197 ms 0.191 ms
# From vm to outside
ping 10.124.12.103
PING 10.124.12.103 (10.124.12.103) 56(84) bytes of data.
64 bytes from 10.124.12.103: icmp_seq=1 ttl=63 time=1.38 ms
The tricky thing is vbox interface does not like normal linux tun/tap interface, I can see interface in VM, but there is nothing I can operate from host, and there is no bridge on the host.
Is there any API I can trouble shooting vbox?
Cheers code farmer
You are right about bridge. Thing here is that your VM is currently behind NAT created by virtual box (see different subnets you mentioned)
What you can do here is to create new bridge on host machine (good instructions HERE)
Using this setup you will have to change networking setting slightly:
VM Host
+-----------------------------------------------------------------+
| -> VM A (10.124.214.5/24) |
Outside network (10.124.214.0/24) -> | eno1 (no IP) -> br0 (10.124.214.4/24) -> VM B (10.124.214.6/24) |
| -> VM C (10.124.214.7/24) |
+-----------------------------------------------------------------+
Then you can assign your VM to br0. Depends on your outside network setting you might need to set static IP to your VM
Finally, I got the root cause:
There are two interfaces in my VM:
First one is NAT, second one is bridge. By default, vbox set the NAT interface as the default route, when I send out packets, it use NAT interface. But HOST and VM are in the same subnet, when connect to HOST, it use the bridge interface. When I need to access this bridged interface from outside, I need to add another entry of default route by ip route command:
sudo ip route add default via 10.124.214.116
I'm running OS X Sierra in VMWare Player on top of Linux Mint 18. I can ping Linux but it won't connect to my server through the browser. I have a separate machine with a test server set up on the same local network. I can reach that one via the browser but not the server on the host. I am trying to connect using IPv4 if that's relevant.
I have tried using 'Bridged', 'NAT' and 'Host Only' to no avail.
Is there some sort of Mac firewall keeping me from connecting with the host?
Any ideas of how to fix?
Edit:
A partial fix from this answer...
I can specify an IP address to the server in the source code (node) but this is obviously sub optimal as the IP addresses are dynamically assigned. This works. I can view it in the guest browser but I have to manually specify the IP address on both ends. How do I get the guest to see the 'localhost' of the host? Essentially I don't want to have to look up my IP address every time I reconnect to my network and change the code to suit.
Edit:
I have another VM guest with Windows 10 running in it with the same issue so it is at least not Mac specific. It is probably something directly related to VMWare.
If you use Bridged network type for the VM.
Try temporary disable local VM OS X firewall:
/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate=off
Temorary disable local server firewall rules:
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
List if IP address of the VM On OS X used same network as your server:
ifconfig
List local server IP address used, it should be from same network as VM IP:
ifconfig
If all firewall rules disabled and both machines (VM OS X and local server) from the same subnet then you should able to ping VM IP address from local server. If addresses from different subnets then use statically assigned IP in the VM OS X or change DHCP assign into your router (that assign IPs if any), you can check MAC address of VM network interface and set it to assign right IP address in the router if any and possible there.
Usually I prefer finding a solution on my own, but unfortunately that didn't work out too well this time so I'm asking here.
I'm trying to deal with a server (rather a computer with no screen and debian minimal on it) which is on the usual home network. Problem is the ISP is running out of ipv4 addresses and therefore
decided to use ipv6 instead and dual-stack lite to access the ipv4 side of the internet. This means the computer is not accessible over the ipv4 address from the outside
but is able to connect to a ipv4 computer.
I do have a vserver (debian as well) which still uses only ipv4, so my plan was to use it as some kind of relay or porxy. Problem there is, I am not able to use iptables to configure NAT
since the server provider has removed that module from the kernel.
My first attempt was to use an SSH tunnel like this:
ssh -f user#vserver -R 2222:localhost:22 -N
This allows me to access the CLI over SSH which now listens on port 2222.
Next step was to open a second SSH tunnel and tunnel UDP traffic through that using socat:
homeserver:~# socat tcp4-listen:${tcpport of second tunnel},reuseaddr,fork udp:localhost:${udpport to forward traffic from}
vserver:~# socat -T15 udp4-recvfrom:${udpport to forward traffic to},reuseaddr,fork tcp:localhost:${tcpport of second tunnel}
This does work, however once the client application is trying to connect to the UDP port, the server application is trying to continue the communication on a different new port from the dynamic
port range (Ephemeral Port Range I think). That one random port of course is not being forwarded since socat is not listening to.
The second attempt also involved an SSH tunnel, only a dynamic one this time (basically a socks proxy).
I was trying to setup a virtual network device to route all the traffic through the socks proxy:
(As described in man pages from badvpn-tun2socks)
homeserver:~# openvpn --mktun --dev tun0 --user <someuser> #create tun0 device
homeserver:~# ifconfig tun0 10.0.0.1 netmask 255.255.255.0 #configure it
homeserver:~# route add <IP_vserver> gw <IP_of_original_gateway> metric #Route all traffic through tun0
homeserver:~# route add default gw 10.0.0.2 metric 6 #exept the ones to the vserver
homeserver:~# badvpn-tun2socks --tundev tun0 --netif-ipaddr 10.0.0.2 --netif-netmask 255.255.255.0 --socks-server-addr 127.0.0.1:1080 \
--udpgw-remote-server-addr 127.0.0.1:7300
This needs to SSH socks-proxies since upd needs to be handled seperately.
On the vserver side of things these need to be handled as well:
vserver:~# badvpn-udpgw --listen-addr 127.0.0.1:7300
The connection between both is successful but this time the homeserver is not accessible at all. (seems to me like the vserver has no clue what to do with the packets)
I hope there is a simple fix to either of my attempts. But as it stands now,
I think my whole approach is fundamentally flawed and I'm starting to run out of ideas.
Any help would be appreciated, Thanks in advance!
Background:
I've recently setup my Cable router in Bridged mode to use Pfsense for OpenVPN and some other features at my house. Once my modems in bridged mode I can only have 1 port connected. So without having another Gbit switch around, I figured I could add a 4 Port HP Intel NIC to my pfsense box and use it similarly to my old setup. This proved to be problematic.
PF Sense Box
Onboard Nic [em4] Set as DHCP to Modem. Bridged mode tested working by my laptop.
HP Nic
[em0] OPT1
[em1] OPT2
[em2] OPT3
[em3] LAN (first port on the card) 192.168.2.0/24
My goal is to Have all Ports on the HP Nic act as a bridge/switch like they did on my modem.
On first Setup: Wan port received its Public facing IP address ok and default rules worked for LAN. So with my laptop wired to LAN everything is a Go. with OPT ports not working as expected.
I enabled all OPT interfaces and set their IPv4 Configuration Type to None as mentioned in the bridge guide.
I added the OPT and Lan interfaces to the bridge0 here: Interfaces > (assign)
Under System > Advanced on the System Tunables
I set:
net.link.bridge.pfil_member 0
net.link.bridge.pfil_bridge 1
For the firewall rules I left OP's blank as I assumed from a guide they would inherit settings from LAN as being set on the bridge. But I have played around with so many firewall settings that I'm not even sure of what to post here for the question. But I've tried setting up default allow all rules for each.
So far I just can't seem to get DCHP connected to OPT's to work. If I set my clients to static I can access the pfsense box. I noticed also that I can communicate with another system via static IP if both are set on different OPT connections. so I guess the bridge is working to some extent. I can also use nslookup with my system set on an opt port with a static IP set but I can't access the web. so it's resolving dns names, but still not allowing traffic. I must be missing some documentation on setting up the rules with a bridged configuration.
Any advice? anyone done it before?
you want:
Each OPT is a different network (VLAN) but leaving by the same port Internet? .. If?.. valid and that the firewall allows navigation for each OPT? (review in the rules, the name OPT)
I have a dual port ethernet NIC and let's say I have connected 2 ports in a loop and assigned the following IPs to the 2 ethernet interfaces:
eth2 -> 192.168.2.1
eth3 -> 192.168.3.1
I want to send traffic from 1 port to another over the physical network, e.g. ping 192.168.3.1 from 192.168.2.1. However, the TCP/IP stack in the Linux kernel recognizes that these two addresses are local and instead sends the traffic to the loopback adapter, so the traffic never hits the physical network.
The closest I have to a solution is Anastasov's send-to-self patch, which unfortunately, has been discontinued since kernel 3.6 so it won't work on Ubuntu 13.10 (kernel 3.11) for me. I've tried finding rewriting the patch for 3.11, but I can't seem to locate these in the Ubuntu distro:
include/linux/inetdevice.h
net/ipv4/devinet.c
net/ipv4/fib_frontend.c
net/ipv4/route.c
Documentation/networking/ip-sysctl.txt
Is there a way I can get the send-to-self patch to work, or an alternative?
You can use network namespaces for this purpose.
As ip-netns's manpage says:
A network namespace is logically another copy of the network stack,
with its own routes, firewall rules, and network devices.
Following is just a copy of this answer:
Create a network namespace and move one of interfaces into it:
ip netns add test
ip link set eth1 netns test
Start a shell in the new namespace:
ip netns exec test bash
Then proceed as if you had two machines. When finished exit the shell and delete the namespace:
ip netns del test
you can try configuring route table, by running "ip" command:
ip route add to unicast 192.168.3.1 dev eth2
ip route add to unicast 192.168.2.1 dev eth3
new route would be added into route table, and it should be able to take effect before egress routing lookup hit the host-local route between "192.168.3.1" and "192.168.2.1", therefore, the traffic should be sent through physical interface "eth2" and "eth3", instead of loopback "lo"
Never tried myself, but should work.