I'm using tcpdump and tcpreplay in ubuntu for capturing packet and resending(with rewriting and openwrt for ap mode in raspberry pi.
My problem is that I cannot capture resent packet.
This is my network :
A ----> B(RPI) -----------> C
192.168.0.199 eth0. wlan0 | 192.168.2.172
192.168.0.100 192.168.2.1 |
------------> D
192.168.2.222
I sent packet(using nping) from A to B, and used portforwarding
nping in A :
nping --udp --dest-port 7777 --dest-ip 192.168.0.100
portforwarding in B using iptables :
iptables -t nat -A PREROUTING -i eth0 --dport 7777 -j DNAT --to 192.168.2.222
So, I done here.
And I write this in D
tcpdump -i wlan0 dst port 7777 -w packet.pcap
tcprewrite -i packet.pcap -o packet_rewrite.pcap -D 192.168.2.222:192.168.2.172
tcpreplay -i wlan0 --topspeed packet_rewrite.pcap
But, in C, I cannot capture modified packet...
tcpdump dst port 7777
I really want to know why i can't...please let me know
and i'm really sorry my explain is not good....
further search.. I captured packets in B (wlan0)
Because i edited packet's source mac to my ubuntu wlan mac address...
But as before, I cannot capture packets in C...
This is captured packets in B
and even replayed packet didn't pass iptables...
I solved!!!!!!!!!!!!!!
I had to change dmac to C's mac address....I was stupid....
Related
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?
I have a system with 2 NIC(eth0,eth1),I connect them externally with a cable (use corssover cable or connect them to a same switch).I want to ping eth1 ip address from eth0 and I want to traffic pass externally (through cable) from eth0 to eth1, but linux kernel send the traffic internally and don't allow it to pass over cable, How can I fix this and send traffic externally?
I use ping with "-I eth0" but the problem exists.
The problem is not with the VRF but with loopback which is used whenever kernel detects it can use it instead sending through the wire.
Let's use real MAC addresses and dummy IP addresses and NAT to force kernel to send data through wire:
arp -s IP0 MAC0
arp -s IP1 MAC1
ip route add IP0 dev eth1
ip route add IP1 dev eth0
iptables -t nat -A POSTROUTING -d IP1 -j SNAT --to-source IP0
iptables -t nat -A POSTROUTING -d IP0 -j SNAT --to-source IP1
iptables -t nat -A PREROUTING -d IP0 -j DNAT --to-destination IP0
iptables -t nat -A PREROUTING -d IP1 -j DNAT --to-destination IP1
First, enslave at least one of the interfaces on different VRF then try ping -l eth0 dest
Some helpful resources about VRF on Linux:
https://www.kernel.org/doc/Documentation/networking/vrf.txt
https://renard.chezwam.org/blog/2014/09/vrf-on-linux/index.html
PS: it is much simpler on BSD(rdomain) :)
I have a network like this:
Internet <===> Modem/Router <---------> Switch
1.2.3.4 192.168.1.1/24 | | |
| | |
+-----+ | +------+
| | |
PC 2 | PC 3
192.168.1.3/24 | 192.168.1.4/24
|
PC 1
192.168.1.2/24
/|\
WLAN
/ | \
PC W1 PC W2 PC W3
192.168.1.X/24 (X>10)
Modem/Router act as DHCP server too. Any request sent on public IP 1.2.3.4 is redirected to 192.168.1.2 on internal network. Modem/Router belong to ISP and I can't access/configure it. PC 1 is a linux box: eth0 and wlan0 are bridged (enslaved to br0 with address 192.168.1.2); hostapd is running on PC 1 sharing internet connection with PC WX. I want to redirect connections to some ports on PC 1 toward PCs on the same net, eg:
1.2.3.4:2222 > 192.168.1.2:2222 -> 192.168.1.3:22
1.2.3.4:3333 > 192.168.1.2:3333 -> 192.168.1.4:25
I tried using iptables and enabling ip_forward
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -d 192.168.1.2 -p tcp --dport 2222 -j DNAT --to 192.168.1.3:22
iptables -t nat -A POSTROUTING -d 192.168.1.3 -p tcp --dport 22 -j SNAT --to-source 192.168.1.2
and so on for others ports, but it didn't work. I discovered that redirections toward any other PC connected via WLAN worked fine. It seems that, using iptables PREROUTING rule in conjunction with a bridge, once a packet has entered the bridge from one side (eth0), it can only flow to the other side (wlan0), but can't go out throw the same input interface. The arrangement described above worked fine when the bridge is disabled, but I dont't want to use PC 1 as a router but as AP only.
Can someone help me?
The rules you've suggested should work with a minor adjustment. Though it's not documented in iptables' man page, you must specify the protocol as the first argument to match, as follows:
iptables -t nat -A PREROUTING -p tcp -d 192.168.1.2 --dport 2222 -j DNAT --to 192.168.1.3:22
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.3 --dport 22 -j SNAT --to-source 192.168.1.2
Note that the second rule is not required since the first rule triggers iptables to take care of the responses automatically.
If it still doesn't work, try disabling iptables invocation while traversing the bridge via echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables and rebooting the machine.
Running linux ubuntu.
Essentially, why is this command a syntax error: -
tcpdump -i eth0 -n udp -X -v -s 1514 'tcp[40:4] = 0x31323334'
Which should show udp packets with '1234' at the 40th byte.
I mean, I get that udp isn't a tcp packet, but the logic should still work. Given it doesn't how can I write this?
try the following:
tcpdump -i eth0 -X -v -s 1514 'udp[40:4] = 0x31323334'
Afaik, proto relop filters should match only the protocol you specify, -n udp should not be needed.
tcpdump is confused what to take as filtering parameter. When you've explicitly used udp, then it captures all the udp packets or if you want particular udp packet then you can specify the offset. So, based on what you need either specify udp with offset or simply udp if you want to capture all the udp packets. Something like below should meet your requirement:
tcpdump -i eth0 -n -X -v -s 1514 'udp[40:4] = 0x31323334'
Assuming that I am the Server, and I want to watch bandwidth of downloading and uploading for the specific MAC address. With the uploading monitor chain. I use this:
iptables -N clientA_upload and then iptables -A FORWARD -m mac --mac-source 00:11:22:33:44:55:66 and it works just fine. - But when it comes to the downloading chain. I use iptables -A FORWARD -m mac --mac-destination 00:11:22:33:44:55:66 and the iptables doesn't support the mac-destination. Please help me out
P/s: I just want to monitor by MAC address. Not ip address. Because in android OS. It doesn't support byte countering using IP address. So please help !!!
For the missing --mac-destination the trick is to combine iptables --mac-source with CONNMARK:
First use --mac-source to match packets coming from the mac address you're interested in.
use CONNMARK to mark the whole connection, ie both directions (!) and
now check packets going in the other direction with the connection mark.
# lan interface
if_lan=eth0
# packets going to mac address will pass through this:
iptables -t mangle -N clientA_download
# mark connections involving mac address:
iptables -t mangle -A PREROUTING -i $if_lan -m state --state NEW -m mac --mac-source 00:11:22:33:44:55 -j CONNMARK --set-mark 1234
# match packets going to mac address:
iptables -t mangle -A POSTROUTING -o $if_lan -m connmark --mark 1234 -j clientA_download
Initially i thought this would only work for tcp connections originating from the lan, but given the definition of --state NEW it should work in both directions for both tcp and udp (!)
For counters see also ipset which is very nice for this.
Policy Routing on Linux based on Sender MAC Address was the inspiration for this answer.
There is no such thing as --mac-destination. You have to move to ebtables for that.
You are confusing downloading and uploading rules.
Rule 1: iptables -A FORWARD -m mac --mac-source 00:11:22:33:44:55:66
is appended to the ipchain and checks the given mac in forwarding chain.
Now you need to check your mac in input chain, so instead of applying the second rule in FORWARD chain, apply it in INPUT chain:
Rule 2: iptables -I INPUT -m mac --mac-destination 00:11:22:33:44:55:66