I want running iptables on Mininet OVS.
I do this
'xterm s1'
'iptables -A INPUT(or FOWARD or OUTPUT) -i s1-eth1 -j DROP' on s1 terminal.
But it is not work.
When I use iptables on Mininet Host, it is work.
How can I running iptables or different packet filter?
please teach me.
You could not use iptables to do packet filter, because OpenvSwitch hooked network device.
All of the packets will through to OpenvSwitch datapath (OpenvSwitch kernel module).
If you want to filter packet in OpenvSwitch, please set flow entry to control your flow tables.
Related
I have a VM running OpenVPN with client-to-client disabled and I need some specific forwarding rules. IP forwarding on the VM is turned on.
The OpenVPN base network is 172.30.0.0/16 and that is further subdivided into /24 subnets with their own rules.
172.30.0.0/24 should have access to all the clients. The rest should not. I have 2 subnets defined at the moment; 172.30.0.0/24 and 172.30.10.0/24.
Following the suggestion at the bottom here;
https://openvpn.net/community-resources/configuring-client-specific-rules-and-access-policies/ - I set up my rules as follows;
iptables -A FORWARD -i tun1 -s 172.30.0.0/24 -j ACCEPT
iptables -P FORWARD DROP
This does not work. If I add a -j LOG at the top, I can see that traffic from my client at 172.30.0.1 connects fine to the client at 172.30.10.3, but all traffic it sends BACK is blocked.
If I set the policy to ACCEPT everything works and I can connect to the client just fine, so this is not a routing problem.
How can I set this up? And why doesn't the suggestion in that OpenVPN guide work?
I solved this by adding
iptables -A FORWARD -i tun1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
which allows established connections to return. Everything works as desired now.
I have a VM in VirtualBox with Debian 10 and I'm trying to NAT masquerade it's output interface (enp0s8) so that it's clients (VMs connected to it) can access the Internet.
All interfaces in the system have an IP. I've already enabled forwarding with:
echo 1 > /proc/sys/net/ipv4/ip_forward
sysctl -w net.ipv4.ip_forward=1
And then I executed:
iptables -t nat -A POSTROUTING -o enp0s8 -j MASQUERADE
However, whenever I execute the above, the following happens:
And no matter how many times I iptables --flush -t nat and repeat the process, the result is always the same. The rule I want to apply is never saved properly and the client's IPs are never masked.
What is the issue here? Almost all tutorials say this is the correct way for masquerading.
I've also tried using nftables, without success.
It is already showing the right output. To show the rules with the interface details, you need to use,
iptables -t nat -L -n -v
And btw, if you have setup NAT networking, it is already taken care to connect outside.
And have you set the default gateway of your clients to this box?
I am facing some problems with tcpreplay. I am running L-7 filter userspace version on ATCA- PP81 blade, and I have this following iptable rules :
iptables -A FORWARD -j NFQUEUE --queue-num 0
iptables -t mangle -A PREROUTING -p udp -i eth0 -j NFQUEUE --queue-num 0
iptables -t mangle -A PREROUTING -p tcp -i eth0 -j NFQUEUE --queue-num 0
I am sending pcap files from a computer using tcpreplay, but all the replayed pcap files except those which have broadcast address were not detected by the iptables. I checked it with:
iptables -t mangle -L -v
I tried many ways, including using a cache file as discussed in some of the forums, and everything is in vain. Now I am totally helpless. I would appreciate it if you could reply my question.
Thanking you in anticipation
regards,
Amlas
It is not possible. This is a tcpreplay limitation.
http://tcpreplay.synfin.net/wiki/FAQ
Can I use IPTables/Traffic Control with tcpreplay?
You can not use iptables/tc on the same box as you run tcpreplay. The only way to use IPTables or Traffic Control (tc) with tcpreplay is to run tcpreplay on a different box and send the traffic through the system running iptables/tc. This limitation is due to how the Linux kernel injects frames vs. reading frames for iptables/tc which makes traffic sent via tcpreplay to be invisible to iptables/tc.
We have a number of iptables rules for forwarding connections, which are solid and work well.
For example, port 80 forwards to port 8080 on the same machine (the webserver). When a given webserver is restarting, we forward requests to another IP on port 8080 which displays a Maintenance Page. In most cases, this other IP is on a separate server.
This all worked perfectly until we installed bridge-utils and changed to using a bridge br0 instead of eth0 as the interface.
The reason we have converted to using a bridge interface is to gain access to the MAC SNAT/DNAT capabilities of ebtables. We have no other reason to add a bridge interface on the servers, as they don't actually bridge connections over multiple interfaces.
I know this is a strange reason to add a bridge on the servers, but we are using the MAC SNAT/DNAT capabilities in a new project and ebtables seemed to be the safest, fastest and easiest way to go since we are already so familiar with iptables.
The problem is, since converting to a br0 interface, iptables PREROUTING forwarding to external servers is no longer working.
Internal PREROUTING forwarding works fine (eg: request comes in on port 80, it forwards to port 8080).
The OUTPUT chain also works (eg: we can connect outwards from the box via a local destination IP:8080, and the OUTPUT chain maps it to the Maintenance Server IP on a different server, port 8080, and returns a webpage).
However, any traffic coming into the box seems to die after the PREROUTING rule if the destination IP is external.
Here is an example of our setup:
Old Setup:
iptables -t nat -A PREROUTING -p tcp --dport 9080 -j DNAT --to-destination $MAINTIP:8080
iptables -a FORWARD --in-interface eth0 -j ACCEPT
iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
New Setup: (old setup in various formats tried as well..., trying to log eth0 and br0 packets)
iptables -t nat -A PREROUTING -p tcp --dport 9080 -j DNAT --to-destination $MAINTIP:8080
iptables -a FORWARD --in-interface br0 -j ACCEPT
iptables -t nat -A POSTROUTING --out-interface br0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
Before changing to br0, the client request would go to server A at port 9080, and then be MASQUERADED off to a different server $MAINTIP.
As explained above, this works fine if $MAINTIP is on the same machine, but if it's on another server, the packet is never sent to $MAINTIP under the new br0 setup.
We want the packets to go out the same interface they came in on, MASQUERADED, as they did before we switched to using a single-NIC bridge (br0/bridge-utils).
I've tried adding logging at all stages in iptables. For some reason the iptables TRACE target doesn't work on this setup, so I can't get a TRACE log, but the packet shows up in the PREROUTING table, but seem to be silently dropped after that.
I've gone through this excellent document and have a better understanding of the flow between iptables and ebtables:
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
From my understanding, it seems that the bridge is not forwarding the packets out the same interface they came in, and is dropping them. If we had a second interface added, I imagine it would be forwarding them out on that interface (the other side of the bridge) - which is the way bridges are meant to work ;-)
Is it possible to make this work the way we want it to, and PREROUTE/FORWARD those packets out over the same interface they came in on like we used to?
I'm hoping there are some ebtables rules which can work in conjunction with the iptables PREROUTING/FORWARD/POSTROUTING rules to make iptables forwarding work the way it usually does, and to send the routed packets out br0 (eth0) instead of dropping them.
Comments, flames, any and all advice welcome!
Best Regards,
Neale
I guess you did, but just to be sure, did you add eth0 to the bridge?
Although, I am not sure what the problem is, I will give some debugging tips which might assist you or other when debugging bridge/ebtables/iptables issues:
Make sure that "/proc/sys/net/bridge/bridge-nf-call-iptables" is enabled (1)
This cause bridge traffic to go through netfilter iptables code.
Note that this could affect performance.
Check for packet interception by the ebtabels/iptables rules,
Use the commands:
iptables -t nat -L -n -v
ebtables -t nat -L –Lc
This might help you to understand if traffic is matched and intercepted or not.
Check that IP NAT traffic appears in the conntrack table:
conntrack –L (if installed)
Or
cat /proc/net/nf_conntrack
Check MAC learning of the bridge
brctl showmacs br0
Use tcpdump on the eth0 and on br0 to check if packets seen at both as expected
Use the –e option to see MAC address as well.
For debugging, try to put the bridge interface in promiscuous mode, maybe the bridge receives packets with different MAC address (in promiscuous mode it will accept different MAC as well)
Maybe set bridge forward delay to 0
brctl setfd br0 0
And disable stp (spanning tree protocol)
brctl stp br0 off
What is your routing table looks like?
Try adding specific or default route rule with "dev br0"
I hope it helps a bit…
Good luck
Well only 1.5 years old but could be useful for later lookups. Looking at your link just now, it says specifically there brouting will ignore the packet, if MAC is on same side of bridge (and not another port or the bridge itself (see fig 2.b in your link).
Adding to that, I simply quote from this link: http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxBridge
"... ebtables DROP vs iptables DROP
In iptables which in most cases is being used to filter network traffic the DROP target means "packet disappear".
In ebtables a "-j redirect --redirect-target DROP" means "packet be gone from the bridge into the upper layers of the kernel such as routing\forwarding" (<-- relevant bit!)
Since the ebtables works in the link layer of the connection in order to intercept the connection we must "redirect" the traffic to the level which iptables will be able to intercept\tproxy.
ANd therein is your answer (bet added for future visitors of course, unless you are still at it ,p)
It seems I don't understand IPTABLES logic.
I reinstalled ubuntu server 11.10 on my server and turned on forwarding (net.ipv4.ip_forward=1 in /etc/sysctl.conf). Server has two network interfaces - eth0 (ip 192.168.1.1) looks to local network and eth1 (ip 213.164.156.130) looks to internet.
There's also another computer in local network with ip 192.168.1.2.
Then I added two simple rules to ITABLE *nat:
-A PREROUTING -i eth1 -j DNAT --to-destination 192.168.1.2
-A POSTROUTING -o eth1 -j SNAT --to-source 213.164.156.130
I thought that the first rule means forwarding every incoming packet to 192.168.1.2.
But if I run "ping google.com", "wget google.com" from server, they successfully work. Server receives packets and doesn't do forwarding, and I'm really stuck with this.
In case I run these commands from 192.168.1.2 they also work, that means here forwarding works.
These are NAT rules.
In your first rule, address translation occurs before routing the packet. You're changing the destination address to 192.168.1.2 and in the second rule, you're changing the source address before routing to 213.164.156.130.
I'm guessing you can ping & wget because your INPUT and OUTPUT chains have a default action.
TBH, I'm confused about what you actually want to do but if you want to forward packets, you need to modify the FORWARD chain. Here's a link for detailed and helpful information on iptables so you can understand the logic better - Ch14:_Linux_Firewalls_Using_iptables">http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:Ch14:_Linux_Firewalls_Using_iptables.