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
Related
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.
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!
It is common to access a container from out of host with simple iptable rules which forward a port on host to a port on container with container internal IP in hand
-A PREROUTING -d 1.2.3.4/32 -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.4.10:80
So public IP 1.2.3.4 will routed to the container. with a proper dns record one can point a FQDN (eg: test.example.com) to this container also. and all things is working good til this point.
BUT in the host or in neighbor containers on same host, the FQDN is useless and not routed to that container.
Currently the dirty way is to point the FQDN to container private IP in /etc/hosts for host and all neighbor containers. but I think there is cleaner way to do that.
Can any one help?
UPDATE 1:
after alot of try and error, got this for host only. by setting this beside above rule it routes packets from host to that FQDN to container
iptables -A OUTPUT -d 1.2.3.4/32 -j DNAT --to-destination 10.0.4.10 -t nat
but nieghbor containers still cannot use that FQDN.
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.
I have been trying to deploy a home-made server. My network consists of a router (Comtrend brand) and 2 pcs (A server laptop connected to eh0 and a netbook connected to WiFi).
The problem is that everytime I try to access to my external public IP I'm redirected to my routers internet address (192.168.1.1).
But if I access with directly with 192.168.1.132 I can see all my services published and use all the protocols. (http, ssh, etc).
What could I do? Is it a problem in the server configuration?
Configuration:
My server's ip is always 192.168.1.132
My laptop receives diferent internal ips but this is not important
My router has a dynamic ip. Let's say X.X.X.X.
Things I've already tried:
1.
I have opened ports in my router. Right now I have:
http 80 80 TCP 80 80 **192.168.1.132** ppp0.1
ssh 22 22 TCP 22 22 192.168.1.132 ppp0.1
2.
I tried with IPTABLES by adding the two next rules:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 192.168.1.132:80
iptables -A FORWARD -p tcp -i eth0 -d 192.168.1.132 --dport 80 -j ACCEPT
Then:
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
You may need to change the router's http management port to some port other than port 80 (like, port 8080 for example), in order to get the port forwarding to work, so that it forwards http requests on port 80 to your server at 192.168.1.132.