|
Once the software is installed on the PC,
and it has recognized all of
the network cards you should be able to see
them by typing at the
console,
interface print
You should see a list of interfaces called
ether1, ether2, and ether3,
and they will probably all have an X next to
them showing they are
disabled. Type in,
interface enable ether1
to enable the first one, and do the same for
the others.
Then type in,
ip address add address10.0.0.1 netmask
255.255.255.0 interface ether2
Check from your workstation if you can ping
it now. If you can, open a web browser
and type in http://10.0.0.1:80/ that will give you the page
where you can download
the Winbox program. It is a GUI interface to
administer the box.
Once you are logged in through Winbox, you
can go to IP and Addresses to set
up the IPs on the other interfaces. You'll
then need to go to IP and Routes and put
in the default route.
That should give you an operational box that
you can now mold into a powerful
router, bandwidth limiter, and logon server.
(and a few other fun things)
For you to gain access to the internet from
your 10.0.0.0 network you'll need to
go to IP and Firewall. Go to the Source NAT
tab, and click on the + symbol.
Enter the following in the appropriate
boxes.
(on the General tab)
Src
Address
10.0.0.0
/ 24
Out
Interface
ether1
(on the Action tab)
Action
Masquerade
To Dst
Ports
49152-65535
Leave all the other settings as they are.
That should properly NAT your
internal network to the outside world. I
like to start the NAT ports at 49152
because that is where the official IANA list
of known ports changes over to
dynamic unassigned ports. It also helps make
things a little less confusing
when you are looking at log captures of what
is going on with a firewall rule.
(more on that in a little bit)
The rest of the router the way it is set up
initially should allow you full access
to the wireless side by simple routing, and
likewise would let the wireless side
access your internal network.
If you want to prevent the latter, go to IP
and Firewall, then on the Filter Rules
tab select the Forward chain in the selector
box on the right side. Click on the +
and enter the following.
(on the General tab)
In
Interface
all
Out
Interface
ether2
Connection
State
established
(on the Action tab)
Action
Accept
Click on OK then click on the +
again.
(on the General tab)
In
Interface
all
Out
Interface
ether2
(on the Action tab)
Action
Reject
Then click on OK.
This does two things. It still allows you to
make connections from your
internal network into the Wireless network.
Your responses will come
back because they are in an "established"
state. Any attempt to connect
to the internal network from the wireless
will be rejected.
NOTE: I AM BY NO MEANS AN EXPERT ON THIS. I
spent the last 3
days playing with this type of stuff trying
to get a radius server and an e-mail
server behind a Destination NAT rule and
it's still not working right.
If you want to run MRTG or some other
monitor on the wireless from the
internal network you'll need to add
something like this.
(on the General tab)
In
Interface
ether3
Out
Interface
ether2
Protocol
UDP
Src
Port
161
(on the Action tab)
Action
Accept
This will allow the wireless equipment to
respond with SMTP data for
your monitoring programs. Be sure and move
it up above any rule that
has an action of Reject. These rules operate
on the packets from the
top down, so if you have a rule above it
that tosses out the packet, it
will never make it to the rule you made to
allow it through. This rule makes
a good example of how to open up a specific
port headed for a specific
network. Remember, if you are going to allow
any access to a specific port
on a server on either the wireless or the
internal from the Internet, you'll have
to use a Destination NAT rule. (something I
haven't quite perfected yet) I'll
tell you a secret though, once you have the
Destination NAT rule set, you
still have to put in the Filter Rules in the
Forward chain a rule to allow the
outside world to talk to that Internal IP
even though it's being NATed. So for
an SMTP server on your internal network...
Destination NAT
(on General tab)
Dst
Address
204.248.28.99 / 32
Protocol
TCP
Dst
Port
25
(on Action tab)
Action
NAT
to Dst
Address
10.0.0.99 - 10.0.0.99
Dst
Ports
25
Filter Rules
(on General tab)
Dst
Address
10.0.0.99 / 32
Protocol
TCP
Dst
Port
25
(on Action tab)
Action Accept
The first forwards their request to the
internal IP address of the SMTP server,
the second allows the packets to flow from
any of the networks to the SMTP
server. This is important because if it
didn't allow access to it from all of the
networks, you wouldn't be able to get to
your e-mail server from your own
workstation. (yup, I did it to myself
once..) This rule also lets your SMTP server
carry on conversations with e-mail servers
on the Internet. Although it doesn't
seem to like it with mine. I think Rockliffe
Mailsite is picky about you moving
it's IP addresses around...
(semi-useful tip # 1)
Make a rule that accepts everything and logs
it. Hit the + then on the action
tab check the Log box. Keep it at the bottom
until you need to see what
packets are moving through where. Change the
IP address, or interface or
port number as needed to capture the packets
you want to look at, and move
the rule up in between the rules that will
allow it to start capturing. When it's
shown in the counters that it has captured
enough packets to satisfy your
requirements, move it back to the bottom and
go look at the log to see what
you've captured. It's very useful for fine
tuning firewall rules. In the log it will
show you which interface the packet came in,
what the source IP was, what
the outgoing interface was, and the
destination IP was. It also shows which
port each IP was using for that
transaction.
Bookmark this too. It's very useful for
figuring out what is trying to go where
and why it's doing it.
As for bandwidth throttling, that is a
question of how you are going to regulate
your users. If you are using PPTP and PPPoE
logins like we are, then you can
set their bandwidth by profile in the PPP
secrets. If you are using RADIUS to
authenticate users for those services, you
can use Ascend-Data-Rate and
Ascend-Xmit-Rate in your RADIUS server
profile to limit their download and
upload speeds.
If anyone that knows MikroTik thinks any of
this is wrong, please speak up.
This is how I've been doing it, and I've
been known to do things wrong on
occasion. (well, ok, more than
that...)
What I wouldn't give for a town of 20,000 nestled in a valley with
short trees
and steep hills all around, and nothing but dialup over bad copper.
8-)
Kevin Summers
|
<<IMSTP.gif>>
