unable to access external IP from LAN - nat

I have a server within OVH network. Proxmox 4.3 was installed there as a supervisor and it's hosting 2 LXC containters. Both are running in 192.168.11.0/24 network setup on vmbr2 network for which I have also setup NAT like that:
auto vmbr2
iface vmbr2 inet static
address 192.168.11.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '192.168.11.0/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.11.0/24' -o vmbr0 -j MASQUERADE
I've also bought Failover IP from OVH, setup virtual MAC for it and assigned it to one LXC container (vmbr0 interface).
My problem is that I can access this IP on LXC server where this IP is assigned (obviously), but I can't do that from other LXC server. Connection just timeout when I simply do wget to it.
What am I missing in my configuration?

I found it. Apparently I missed routing entry on main host:
route add -host failover_ip gw main_ip
Thanks to this all LXC hosts have now access to my Failover IP.

Related

OpenVPN - How do you NAT a client to another client's network

I have a openVPN server setup on a AWS instance and I would like to use it to route traffic from my home client (client1, 192.168.0.0/24) to a client(client2, 10.81.0.0/16) on a machine on a second network through the openVPN server. I want to route the connections from client1 to client2's network so that I can connect to several devices in client2's network. However I dont have control over the gateway in client2's network so I can't add a route back to the vpn.
As far as I can tell I have the openVPN configuration setup in that once client1 and client2 are connected I can access client2 from client1, the routes are also setup so that if I ping a machine on client2's network the traffic is routed through the vpn but no response happens as client2's network devices do not know how to route the vpn ips back to client2.
I am assuming that I need to setup nat masqurading at client2 but I am unsure how to properly handle this as I am not that familiar with iptables.
tried on client2:
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
server.conf
port 1194
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
route 10.81.0.0 255.255.0.0
push "route 10.81.0.0 255.255.0.0"
dh none
ecdh-curve prime256v1
... encryption info ...
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3
ccd/client2
iroute 10.81.0.0 255.255.0.0
For anyone with a similar issue, I found this https://arashmilani.com/post?id=53 that helped me solve the issue.
For me I needed to add the following instead of what I tried.
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eno2 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eno2 -o tun+ -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno2 -j MASQUERADE
tun0 is the tunnel interface from the VPN and eno2 is the interface for client2's network. 10.8.0.0/24 is the default subnet for the VPN subnet.
The forwarding was the big issue, also the masquerade is based on the ip address range of the VPN on the output interface.

Using Squid and/or iptables to share ip address over a bridge

Edited for additional clarity and added links to other attempted solutions.
I have been attempting this for several days now with one other developer, and we are getting nowhere and there are a number of comments on-line about how there are no examples to do this sort of thing (including someone who wrote some c code to do something similar though not exactly this). We have attempted to implement the solution described on SuperUser as well, but so far it does not seem like the local http server receives any of the requests as expected.
What we are trying to do:
On a device (test device) that sits between another device (mini computer) and the network. We want the test device to use the ip address of the mini computer to communicate with the control server -- in other words, we don't want it to have to have its own IP address but use that of the minicomputer for control commands (e.g., block network traffic, resume network traffic). Things are set up like so:
Mini Computer| | Test Device | | LAN
Ethernet |<-->|eth_minicomp<-->br0<-->eth_network|<-->| Ethernet
So for traffic that is:
coming from the control IP address, AND
destined for the mini computer IP address
We want the test device to intercept (and NOT forward), but use locally.
Whereas for traffic that is:
comping from the test device, AND
destined for the control IP address
We want it going out the eth_network interface with the src address being the mini computer ip address.
Latest Attempt
I have a device set up as a transparent bridge which works:
# Bring interfaces down
ip link set dev eth_minicomp down
ip link set dev eth_network down
# Create bridge
ip link add name br0 type bridge
ip link set dev br0 up
# Remove IP addresses from interfaces
ip address flush dev eth_minicomp
ip address add 0.0.0.0 dev eth_minicomp
ip address flush dev eth_network
ip address add 0.0.0.0 dev eth_network
# Bring interfaces back up
ip link set dev eth_minicomp up
ip link set dev eth_network up
# Set promisc (not sure about on br0, but should not have an effect)
ip link set dev eth_minicomp promisc on
ip link set dev eth_network promisc on
ip link set dev br0 promisc on
# Add interfaces to bridge
ip link set dev eth_minicomp master br0
ip link set dev eth_network master br0
I had been hoping to use iptables/tproxy or perhaps Squid to handle this by routing the desired TCP/IP traffice to lo (127.0.0.1), but cannot seem to get this to work. My latest attempt was trying to use
sysctl net.ipv4.ip_forward=1
sysctl net.ipv4.conf.lo.rp_filter=1
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -N DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 0x01/0x01
iptables -t mangle -A DIVERT -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A PREROUTING -s $CONTROLLER_IP -p tcp -j TPROXY \
--tproxy-mark 0x1/0x1 --on-port 80
ip route flush table 100
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
TPROXY seem to require at least the net.ipv4.ip_forward set 1,2, however, following the procedure on the Squid TPROXY Feature page does not seem to be set up for this type of solution.
And various permutations on -s, -d, --on-port, etc. It seems that I could use the Suid man in the middle setup to do something like this, but I do not see how. Trying to search for Suid man in the middle or Squid localhost proxy on SO returns a lot of not-quite-what-i'm-looking-for questions.
So how do we route these packets to a local server on the test device for handling? RTFM responses are more than welcome, we just cant find the fabulous manual.
Got it working with help from a team member using ebtables and iptables.
The biggest surprise in getting this working was finding out that if you use ebtables to create an Ethernet bridge, you have to DROP the Ethernet frames in order for them to get kicked up to the network layer. We all thought that DROP actually dropped the Ethernet frame and therefore the TCP/IP packets. Go figure.
We now have a device that can share the MAC and IP address of the computer to which it is attached and still communicate without disrupting the computer.
INT_IP=169.254.1.1
SRC_IP=192.168.1.2
DST_IP=192.168.1.3
EXT_PORT=80
INT_PORT=54321
# Bring interfaces to bridge down
ip link set dev eth1 down
ip link set dev eth2 down
# Remove any ip addresses on the interfaces
ip address flush dev eth1
ip address flush dev eth2
ip address add 0.0.0.0 dev eth1
ip address add 0.0.0.0 dev eth2
# Bring interfaces back up
ip link set dev eth1 up
ip link set dev eth2 up
# Set promiscuous on the interfaces
ip link set dev eth1 promisc on
ip link set dev eth2 promisc on
# Create bridge
ip link add name br0 type bridge
ip link set dev br0 up
# Add interfaces to bridge
ip link set dev eth1 master br0
ip link set dev eth2 master br0
# Add a local private IP to the bridge
ip address add $INT_IP dev "br0"
# Allow forwarding
sysctl -w net.ipv4.ip_forward=1
# Set up ethernet bridge with ebtables.
# NOTE the drop. Completely counterintuitive.
ebtables -t broute -A BROUTING -p IPv4 --ip-source $SRC_IP \
--ip-destination $DST_IP --ip-proto tcp --ip-dport \
$EXT_PORT -j redirect --redirect-target DROP
ebtables -t broute -A BROUTING -p IPv4 --ip-proto tcp \
--ip-sport $INT_PORT -j redirect --redirect-target \
DROP
# Set up iptables to handle diverting requests that originate
# from $SRC_IP destined for $DST_IP on port $EXT_PORT and send
# them to $INT_IP and $EXT_PORT in stead where you can have a
# service / thingy to handle them.
iptables -t nat -A PREROUTING -p tcp -s $SRC_IP -d $DST_IP \
--dport $EXT_PORT -j DNAT \
--to-destination $INT_IP:$INT_PORT
iptables -t nat -A POSTROUTING -p tcp -d $INT_IP \
--dport $EXT_PORT -j SNAT --to-source \
$DST_IP:$EXT_PORT
iptables -t nat -A POSTROUTING -j MASQUERADE
Now if you try to reach $DST_IP on port $EXT_PORT from $SRC_IP, it will be routed to $INT_IP on $INT_PORT in stead. Conversely, if you try to send data to $INT_IP on $INT_PORT from the system on which you configured this, all traffic will go to $SRC_IP on $EXT_PORT
-2 karma! Woohoo!

Can't get Network in User-Mode-Linux

I am developing a kernel feature, using User-Mode-Linux.
I compiled 3.12.38 from source and downloaded a Debian fs.
However, I am not able to seet-up networking using following options here.
Are there any good source or info to go with this.
I have internet on wlan0.
EDIT:
I start with eth0=tuntap,,,192.168.0.254
and then inside UML UML# ifconfig eth0 192.168.0.253 up
I only get the output as:
modprobe tun
ifconfig tap0 192.168.0.252 netmask 255.255.255.255 up
route add -host 192.168.0.253 dev tap0
As mentioned, output is lacking a bit and more over a ping to 192.168.0.254 doesn't seems to work, with 100% packet loss.
Let us follow the steps to establish the following Topology:
VM-tap0(192.168.6.6)-------------(192.168.6.8)eth0-UML1-eth1(192.168.20.1)----------------eth1-(192.168.20.2)UML2
here, UML1 and UML2 are two UML instances running on VM as a host.
All uml_console commands are suppose to run on VM host.
Tun/Tap config:
VM <------>UML1 (ley us first establish the connection between VM host and UML1)
#host as root :
chmod 777 /dev/net/tun
tunctl -u vm -t tap0 (here vm is the VM user name)
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp
ifconfig tap0 192.168.6.6 up
./linux ubda=CentOS6.x-x86-root_fs umid=debian1 [separate terminal]
uml_mconsole debian1 config eth0=tuntap,tap0
route add -host 192.168.6.8 dev tap0
route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.6.8 dev tap0
#uml1
eth0=tuntap,tap0
ifconfig eth0 192.168.6.8 up
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
Now UML1<-------------->UML2
./linux ubda=CentOS6.x-x86-root_fs2 umid=debian2 [separate terminal]
uml_mconsole debian1 config eth1=mcast (if these commands fails, it means you have not compile the UML kernel with multicast ineterface enabled in )
uml_mconsole debian2 config eth1=mcast
again #uml1
ifconfig eth1 192.168.20.1 up
#uml2
ifconfig eth1 192.168.20.2 up
route add -net 192.168.6.0 netmask 255.255.255.0 gw 192.168.20.1 dev eth1
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
Try ping UML2 from VM and vice versa. You should be able to ping in both directions.

L2TP / PPTP server with multi external IP

I have a Debian VPS with 2 IP addresses : example 1.1.1.1 and 2.2.2.2
I've already setup a PPTP service and a L2TP service that work great.
When a VPN client connect to the VPS (IP 1.1.1.1) : his public IP address is 1.1.1.1
But the issue is that when a VPN client connect to the VPS (IP 2.2.2.2) : his public IP address is still 1.1.1.1 instead of 2.2.2.2
How can I fix this ?
Thanks !
assuming you have multiple pptpd listening on 1.1.1.1 and 2.2.2.2 with different configurations for their subnets and also the interfaces are actually up (eth0, eth0:1 etc.)
i.e.
for 1.1.1.1 you could use a config like this (lets call it config1)
option /etc/ppp/pptpd-options
logwtmp
localip 192.168.30.1
remoteip 192.168.30.2-100
and for 2.2.2.2 (lets call it config2)
option /etc/ppp/pptpd-options
logwtmp
localip 192.168.50.1
remoteip 192.168.50.2-100
then listen on both ip's like this
pptpd --listen 1.1.1.1 --conf config1
pptpd --listen 2.2.2.2 --conf config2
you would then use iptables rules like this
iptables -t nat -A POSTROUTING -s 192.168.30.0/24 -o eth0 -j SNAT --to-source 1.1.1.1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o eth0 -j SNAT --to-source 2.2.2.2

How-to setup a traffic control server

I am trying to set up a traffic control server between the network and the firewall-router.
The server has two network devices:
Firewall <--> Server <---> NETWORK
It is running CentOS 6.4 x64 and I would like to use Etherape.
My idea is to have eth0 connected directly to our router and eth1 to our network.
eth1 would have two virtual interfaces, one with an IP to ssh the server and the other just forwarding with IPTables to eth0 with no IP. Of course, eth0 would not have any IP (we don't want to change the Gateway).
Any suggestion or better way to do this?
Thank you very much!!
Ok, finally it was quite easy. Install brctl and etherape, then:
brctl addbr br0
brctl stp br0 off
brctl addif br0 eth0
brctl addif br0 eth1
echo 1 > /proc/sys/net/ipv4/ip_forward
ifconfig eth0 up
ifconfig eth1 up
ifconfig br0 up
service network restart
ifconfig br0 XX.YY.ZZ.AA
That is a temporal configuration. If you reboot you have to re-do it. Here is a way to make it persistent:
http://www.tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO.html#toc3.3
Finally, (installing if you are in a Windows Box, Xming and Putty and) connecting as root to XX.YY.ZZ.AA with X11 redirection, execute etherape and you will have you remote traffic control.
To make it easier, I will recommend to add the filter:
ip and not ((src net XX.YY.ZZ.AA) or dst net XX.YY.ZZ.AA)
To avoid the X11 traffic between the server and your box.

Resources