iptables forwards traffic, but does not receive responses - linux

So I'm currently trying to use a raspberry pi as a sort of range extender where you connect wlan0 to an access point, and the hostapd AP setup on the interface wap0 routes all traffic through wlan0. The chain would look like this:
Wireless Client---> wap0 AP ---> wlan0 ---> Network Gateway ---> Internet
I currently have my iptables rules setup as follows:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -i wap0 -o wlan0 -j ACCEPT
-A FORWARD -i wlan0 -o wap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A POSTROUTING ACCEPT
-A POSTROUTING -o wlan0 -j MASQUERADE
ip_forward is also set to 1
What I've found after looking at some tcpdumps is that the outgoing traffic from wap0 to wlan0 does in fact get forwarded, but I never receive any responses to this traffic on wlan0. If the traffic originates from the raspberry pi (like a ping to www.google.com), I get a response. However any traffic coming from a client connected to wap0 and routed through wlan0 gets no response.
It is worth noting, however, that even when I flush all of the ip rules and fire up a tcpdump session on wlan0, I can still see traffic from wap0 being routed to the interface.
wap0 is setup to put all of its clients on the 192.168.8.0/24 subnet, and the subnet of the network wlan0 is connected to is 10.118.30.0/24. Does anyone know what I'm doing wrong?

Related

Why i see DST="127.0.0.53" on -j REDIRECTed packets?

I am confused about situation in my NATed network. I start dnsmasq on router, with listen-address=192.168.100.1 and -p 5353 option for DNS port. Afterwards, i add iptables rule for hosts inside that network:
iptables -t nat -I PREROUTING -s 192.168.100.0/24 \
-d 192.168.100.1 -p udp --dport 53 -j REDIRECT --to-ports 5353
But this didn't work first time, since my INPUT policy is DROP: when i add this rule, everything starts to work:
iptables -I INPUT -p udp --dport 53 -d 127.0.0.53 -j ACCEPT
I discovered this address with help of -j LOG on my INPUT chain, where i saw packets dropped like SRC=127.0.0.1 DST=127.0.0.53 ..., when NATed host is trying to resolve hostname.
As i am writing automated script that generates correct netfilter rules for situation, i need to know from where this 127.0.0.53 could come from.
I see the same address in /etc/resolv.conf. But i don't understand who's routing this packet to this address when it is "redirected", if even close to understanding what happens.
systemd-resolved sets up a stub listener for dns requests locally on 127.0.0.53:53
try disabling it to proceed sudo systemctl disable systemd-resolved

dns configuration for wireless access point

I am trying to implement wireless access point on my embedded platform. I have implemented some parts like running wireless card as access point, dhcp server and some forwarding rules (via iptables).
I have tried several iptables commands. results of all are the same. The last one I decided to use is:
iptables -t nat -F
iptables -F
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
echo '1' > /proc/sys/net/ipv4/ip_forward
Access point runs successfully, clients can connect to it and get ip address. However there is DNS problem. Clients could not resolve the hostnames but they can connect via ip addresses.
DHCP configuration is as below:
interface wlan0
start 192.168.7.11
end 192.168.7.20
max_leases 10
option subnet 255.255.255.0
option router 192.168.7.1
#option dns 192.168.7.2 192.168.7.4
option domain local
option lease 864000
lease_file /conf/udhcpd.leases
#pidfile /tmp/udhcpd.pid
For this configuration, If I use 'option dns 8.8.8.8 8.8.4.4' I can resolve the problem but I need to use the dns of the network. Is there any way to forward the dns address 192.168.7.2 to the dns address of the wired network (eg. 192.168.0.2).
I could not find the DNS routing (eg. 192.168.7.2 to 192.168.0.2). But I have found a way to use the DNS address of the embedded platform on clients.
in DHCP server configuration, I used this option:
option dns 192.168.0.2 192.168.0.4 (conf file are generated when access point is started, so the dns addresses are obtained from the system )
after DHCP server is run, I have run these commands to forward dns addresses:
iptables -A FORWARD --in-interface eth1 -m tcp --sport 53 -j ACCEPT
iptables -A FORWARD --in-interface eth1 -m udp --sport 53 -j ACCEPT

linux PPTP server relay

I want to create a VPS both has PPTP server and client, and this VPS is used as a relay.
There are two server: VPS1 and VPS2, both install PPTPD, and VPS1 install pptp client.
I want have this:
user ---- PPTP ----> VPS1 ----- PPTP ----> VPS2
user connect to VPS1, and all the network traffic route to VPS2.
I'm doing this because user is hard to connect VPS2 directly, need an middle server to work as relay.
How can I config iptable to make it work? Thanks.
Strange usage of PPTP. Your ISP must be Shanghai, China Telecom.
If you route all the network traffic in VPS1 to VPS2, you have to know the IP address of user and setup an exception. Or the user will never receive the reply packets.
Maybe you can use iptables to enable DNAT. Make VPS1 as a router and VPS2 as the internal pptp server.
First of all, you should check if the kernel module ip_nat_pptp and ip_conntrack_pptp is loaded. PPTP use TCP port 1723 to transmit control commands and use GRE to transfer data. Because the GRE has no port, the server has to use the CallID to track the endpoints and implement the NAT. This is called PPTP Passthrough.
# lsmod | grep pptp
If not loaded, then load them.
# modprobe ip_nat_pptp
# modprobe ip_conntrack_pptp
Then you need to enable the IPv4 network forwarding:
# sysctl -w net.ipv4.ip_forward=1
Now you can create iptables rules to accept the incoming and forwarding request:
# iptables -A INPUT -d $VPS1_IP_ADDR -p tcp --dport 1723 -j ACCEPT
# iptables -A INPUT -d $VPS1_IP_ADDR -p gre -j ACCEPT
# iptables -A FORWARD -d $VPS2_IP_ADDR -p tcp --dport 1723 -j ACCEPT
# iptables -A FORWARD -d $VPS2_IP_ADDR -p gre -j ACCEPT
Finally setup the DNAT rules:
# iptables -A PREROUTING -d $VPS1_IP_ADDR -p tcp --dport 1723 -j DNAT --to-destination $VPS2_IP_ADDR
# iptables -A POSTROUTING -d $VPS2_IP_ADDR -p tcp --dport 1723 -j MASQUERADE
You can connect VPS1 with username/password of the pptpd on VPS2 now.

networking is not working on qemu guest (Malta Mips)

I am trying to configure networking on QEMU malta mips, which is running on vmware host (ubuntu) using tap/tun device and bridge interface. My qemu guest is unable to retrieve ip address from DHCP server. If i give it manually, it can just connect with its host. Using tcpdump i came to know that outgoing traffic is working perfectly but incoming is not working.
Can anyone suggest me how to solve this kind of issue?
Thank You
If you use NAT mode, then your host machine will act as a router for your guest VM. This means you must enable routing on your host.
Assuming you start qemu and link it to tap0 interface and your outgoing internet interface is eth0, then you should:
Create the tap0 virtual interface:
tunctl -t tap0
ifconfig tap0 192.168.0.1 netmask 255.255.255.0 up
Activate routing
# activate ip forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# Create forwarding rules, where
# tap0 - virtual interface
# eth0 - net connected interface
iptables -A FORWARD -i tap0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tap0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Start your VM with somenthing like this:
qemu [..] -net nic,model=e1000,vlan=0 -net tap,ifname=tap0,vlan=0,script=no
In your VM, configure an interface with ip 192.168.0.2/24 and default gateway 192.168.0.1
In NAT mode you can't achieve this. You need to configure VM in bridge mode and I hope you know the steps to configure it; if not see the link here ;
Step #2 of catalin.me's answer could be even simpler:
# activate ip forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
First two iptables rules are needed only in case if default policy for FORWARD chain is DROP.
E.g.:
iptables -P FORWARD DROP

Meteor on Multihomed Server?

Does anybody have any experience running Meteor on multihomed servers? We're bring an app into production, and have some servers that have two network cards each. The one interface on eth0 connects to our internal network with our Mongo cluster, and the other interface eth1 connects to our DMZ. We're well past development, and are in post-bundle workflow. So, it's a question of running the following command only on eth1:
MONGO_URL='mongodb://mongodb:27017/?replicaSet=meteor' PORT='80' ROOT_URL='http://app.domain.org' node main.js
I don't know enough about node to know exactly how to specify a single interface. Is this specified with an environment variable? In our /etc/network/interfaces file? iptables? Something else?
I'm finding resources like the following on the web, but I'm not sure if I'm on the right track with them. Does getting a node.js server running on a specific interface require this kind of fussing? Is there something easier?
https://gist.github.com/logicalparadox/2142595
how to set node.js as a service on a private server?[can't access the node application]
Any help would be much appreciated! Thanks!
Abigail
Meteor will listen on 0.0.0.0 (all interfaces) unless your specify the environment variable BIND_IP.
Explicitly- the value of BIND_IP is passed as the hostname parameter to http://nodejs.org/api/http.html#http_server_listen_port_hostname_backlog_callback
Source: https://github.com/meteor/meteor/blob/master/packages/webapp/webapp_server.js#L541
Okay, so got things working. Second ethernet card wasn't configured.
sudo nano /etc/network/interfaces
auto eth0
iface eth0 inet static
address aaa.bbb.ccc.ddd
gateway aaa.bbb.ccc.eee
auto eth1
iface eth1 inet static
address aaa.bbb.ccc.fff
gateway aaa.bbb.ccc.ggg
sudo ifconfig eth1 up
sudo /etc/init.d/networking restart
Then had to make sure firewalls were working...
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -L -n -v
Then confirmed the site was running on the correct IP address with a big of curl...
curl -XGET http://aaa.bbb.ccc.fff/main.js

Resources