IpTables

back to http://scratchpad.wikia.com/wiki/Sasecurity

TableOfContents

Blocing an IP with users sharing same MAC
Cheers Kenny Did the trick, got a phone call this morning. just used * iptables -A INPUT -s 192.168.xxx.xxx -j DROP * iptables -A OUTPUT -s 192.168.xxx.xxx -j DROP

Then removed them after the customer went back to DhCp.

I wonder if he could also use iptables to do this?

* iptables -A INPUT -s 192.168.xxx.xxx -j DROP * iptables -A OUTPUT -s 192.168.xxx.xxx -j DROP * iptables -A FORWARD -s 192.168.xxx.xxx -j DROP * iptables -I INPUT -s 192.168.xxx.xxx -j DROP * iptables -I OUTPUT -s 192.168.xxx.xxx -j DROP * iptables -I FORWARD -s 192.168.xxx.xxx -j DROP

I'm not sure if all of this is needed, but this is what I did before to solve just such a problem and it worked.

> Can anyone tell me a command to block a ip address that a user has > given > them self's! I.e. they have set a static ip address in there router or > pc. > As they have set a static ip address, they do not show in the dhcp > list, and > i can not drop them! I can not use blocknode or mac as this users shares a mac with other > users? But I need to block this static ip address in order to get a telephone call  from them so I get to find out who they are.

adsfsdf
Thanks Joel, I tried this on the Reeth Rural Radio Net (RRRN) email issue this afternoon. At first it didn't work, but once I'd created a firewall rule on the mesh box attached to the mail server it worked!

The rule I added was:

iptables -t nat -A POSTROUTING -p tcp --dport 110 -j MASQUERADE

> We have come up with a solution for redirecting some traffic over the > mesh, even when there are multiple gateways on the mesh. This can be > used for passing pop traffic over the mesh to a local server, running > a local web server or any other local service. > > Details are written up at >  > > and if it is clear as mud, please get back to me and I will try to > clarify the page. > > The problem with host mapping is that it only works from the gateway > down to the node. If you are on a different gateway, then you have to > go out the default route and in the other gateway. This allows > clients to talk across a contiguous mesh with multiple gateways. > > NB - if you set this up and your mesh splits due to a linking node > going down, then your customers will not be able to access the local > server. If you are going out via the internet, then a split mesh will > still function.

I've just taken a look and it's as clear as a bell. A great solution. I've been thinking... Would it be possible to specify vpnhost. as the pop server in a mail client? This would mean that if a user roamed across nodes their access to the POP server would be maintained without traffic being passed over the mesh to the wiana IP address of the node specified (as in your documentation) before being rerouted to the 192.x.x.x address

=
========================== I think you might be missing the point - the 1.x.x.x address used as the POP server will be the address of the meshnode that has the server attached, not the client.

As an example:

1.2.3.4192.168.1.1 (POP server)

1.2.3.5192.168.123.210 (client)

1.2.3.6			(third mesh node)

The port mapping is set up on 1.2.3.4 and this redirects traffic on the br interface to 192.168.1.1

The client is set up to use 1.2.3.4 as the POP server. It doesn't matter where in the mesh the client is, or which node it is connected to, it will try to connect to 1.2.3.4 via which ever node it is connected to. This then gets mapped through to 192.168.1.1 on the ethernet interface of 1.2.3.4.

So you should be able to roam quite happily.

The only bit I'm not sure about yet is what happens to users connected wirelessly to the 1.2.3.4 node.

It might work better by translating 1.2.3.4:110 to 192.168.1.1:110 - perhaps some more testing required....

addrettgg adsfa
> By default, MeshAP won't let two wireless clients talk to one another > a sensible precaution. > How is this implemented? A simple iptables rule. > Is there any way to turn it off for a specific > host? Uncheck "Same node clients firewalled" In Wiana for your 2 meshaps. > So that all wireless clients can access a server on another > wireless client?

Yes. But don't forget, if one of this client is on the uplink, you have to add a route manually on the uplink (because the default uplink route is the internet).