Arsip Kategori: jaringan komputer dan mikrotik

jaringan. mikrotik

Conficker dan bagaimana mengenalinya


source : awarmanf.wordpress.com

Sebenarnya sudah cukup banyak tulisan yang dibuat mengenai conficker:

1. Apa itu conficker
2. Blocking virus conficker
3. Download domain conficker
4. Memblok akses untuk download content conficker

Tulisan yang akan disajikan di bawah ini pendekatannya hampir sama dengan cara 2 dan 3 cuma scriptingnya tidak dilakukan di mikrotik melainkan di laptop ubuntu penulis. Data domain conficker diambil dari http://www.epicwinrar.com/conficker/domains.txt. Langkah-langkahnya sebagai berikut:

1. Download data domain conficker.
2. Buat script untuk query setiap domain conficker.
3. Extract alamat ip domain conficker yang exist (resolvable).
4. Sortir ip conficker yangg diperoleh dari domain yang exist dan cari ip conficker yang kemunculannya paling banyak (modulus).
5. Berdasarkan ip conficker yang diperoleh dari no 4 di atas, cari kemunculannya di ip dns cache mikrotik.
6. Jika ada datanya, masukkan ip tersebut ke ip firewall address-list untuk diproses lebih lanjut.

Sebenarnya langkah ini bisa lebih singkat yakni sampai nomor 3 saja, langkah selanjutnya adalah masukan domain conficker yang exist tersebut seperti yang dijelaskan di http://wiki.mikrotik.com/wiki/Conficker-Virus-Blocking. Domain conficker yang exist ada sekitar 30 ribu lebih. Apa puluhan ribu data ini mau dimasukkan semuanya ke ip firewall address-list ? Karena belum tentu domain conficker ini meski ada (exist), juga aktif sebagai inang conficker. Beberapa domain conficker sudah diambil alih dan dihandle oleh badan yang namanya Conficker Holding Account. Cek siapa yang memiliki domain conficker qvqgzdwrnnr.info. Disitu jelas tertulis data lengkap pemegang domain. Apakah ini benar alamat yang si pembuat virus conficker? Tidak mungkin kan ? Padahal Microsoft menjanjikan uang $250,000 bagi siapa yang bisa membekuk si biang kerok ini.
Domain ini kalau kita buka di browser dan pakai opendns, aksesnya diblok seperti ditunjukkan pada gambar di bawah:
akses ke qvqgzdwrnnr.info diblok oleh opendnsSebenarnya yang penting di sini adalah bukanlah mencari dan memilah ini domain conficker exist (dan aktif) atau bukan melainkan mencari client-client mana yang terkena virus conficker dan aktif melakukan request ke domain-domain conficker meski domain yang dituju sudah tidak exist atau dormant sehingga bisa diambil tindakan:

1. Memberitahu client bahwa jaringan atau pcnya terkena virus conficker.
2. Jika ada client yang mengeluh koneksi internet lambat, itu karena dampak virus conficker :) .

Tambahan lagi apakah mikrotik tidak terkena dampak dari sebaran virus conficker ini? Dns cache mikrotik di sini sudah 2x pada hari yang sama mengalami cache size dns terpakai semua (baca cache used > cache size), sebagai akibatnya request dns dari client lambat atau gagal! Untuk itu langkah pencegahan di sisi mikrotik:

1. Besarkan dns cache.

/ip dns set cache-size=10240

2. Buat schedule untuk meng-flush dns cache apabila pemakaiannya melebihi nilai tertentu. Script di bawah akan flush dns cache bila ukurannya lebih dari 5120KiB.

:local a [ /ip dns get cache-used ];
:if ($a>=5120) do { /ip dns cache flush };

Langkah pertama, download domain conficker:

$ wget -O domains_conficker.txt \

http://www.epicwinrar.com/conficker/domains.txt

Langkah kedua, buat script untuk query setiap domain conficker yang diperoleh dari cari di atas:
view source
print?
#!/bin/bash
#
# File: cek_domains_conficker.sh
#
CONFICKER=”domains_conficker.txt”
DNSISP=”1.2.3.4″
cat $FILE | while read domain
do
ip=`dig @$DNSISP +time=1 +short $CONFICKER`
echo “$CONFICKER:$ip” >> ip_domain_conficker.txt
done

Jalankan dengan perintah bash cek_domains_conficker.sh
Ekseskusi ini akan memakan waktu lama karena ada 113501 domain conficker sejak tulisan ini dibuat yang perlu dicek exist tidaknya. Sebelum menginjak langkah ketiga, coba kita lihat sebagian data ip_domain_conficker.txt yang diperoleh dari langkah no 2:

qegiche.ws:64.70.19.33
ovdbkbanqw.com:
lxmpzyiq.com:
gkrobqo.com:
hunqbpya.net:
lmhfcocgiz.org:
epzyytco.ws:64.70.19.33
ampavhunh.com:
pzzyxnzhuv.com:
frdyiaosiir.ws:64.70.19.33
kvfvpszaxv.biz:
gopfgie.net:
ibrdykqf.ws:149.20.56.32
199.2.137.252
205.188.161.4
74.208.64.145
83.68.16.6
97.74.200.45
143.215.143.11
xwfxr.ws:205.188.161.4
74.208.64.145
83.68.16.6
97.74.200.45
143.215.143.11
149.20.56.32
199.2.137.252

Terlihat bahwa ada beberapa domain conficker yang tidak exist ditunjukkan dengan warna abu-abu. Beberapa domain memiliki multi ip address.

Langkah ketiga di bawah untuk mengekstrak ip domain conficker yang exist dan menyimpan hasilnya ke file ip_domain_conficker_exist:

$ grep -oe “[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*” \
ip_domain_conficker | sort > ip_domain_conficker_exist

Langkah keempat buat script untuk menghitung jumlah ip yang sama berdasarkan data ip_domain_conficker:
view source
print?
#!/bin/bash
# File: hitung_modulus_ip_conficker.sh
file=ip_domain_conficker_exist
i=0
iplama=’Inisialisasi’
while read ipbaru
do
if [ $ipbaru == $iplama ]
then
i=$((i+1))
else
i=$((i+1))
echo “$iplama: $i”
i=0
iplama=$ipbaru
fi
done <$file
echo "$iplama: $((i+1))"
done

Jalankan scriptnya bash hitung_modulus_ip_conficker.sh.
Beberapa baris hasil perintah di atas ditunjukkan pada tampilan di bawah:

Inisialisasi: 1
110.75.195.7: 2
113.11.195.12: 1
114.167.126.140: 1
116.254.252.21: 1
117.74.76.174: 1
119.42.231.250: 6
121.101.213.189: 1
12.180.115.1: 1
122.249.22.110: 1
123.100.2.87: 1
124.217.198.74: 1
124.248.32.60: 1
124.42.122.43: 1
124.42.8.188: 1
124.47.0.2: 1
125.72.127.36: 1
127.0.0.1: 2
143.215.143.11: 30508
149.20.56.32: 30574
161.58.230.16: 1

Daftar ip conficker yang mempunyai frekuensi kemunculan terbanyak (tidak diurut berdasarkan ranking):

64.70.19.33
66.90.81.140
72.167.51.186
74.208.46.216
74.208.64.145
83.68.16.6
97.74.200.45
143.215.143.11
149.20.56.32
199.2.137.252
205.188.161.4
221.7.91.31

Langkah kelima, ambil salah satu ip yang kemunculannya terbanyak, 221.7.91.31, cek apakah datanya ada di ip dns cache mikrotik (penulis gunakan mikrotik versi 3.30, versi sebelumnya kemungkinan tidak mempunyai filtering untuk menampilkan kolom data):
ip conficker di dns cache mikrotik

Langkah keenam, buat rule di ip firewall address-list:

/ip firewall address
add address=64.70.19.33 list=conficker
add address=66.90.81.140 list=conficker
add address=72.167.51.186 list=conficker
add address=74.208.46.216 list=conficker
add address=74.208.64.145 list=conficker
add address=83.68.16.6 list=conficker
add address=97.74.200.45 list=conficker
add address=143.215.143.11 list=conficker
add address=149.20.56.32 list=conficker
add address=199.2.137.252 list=conficker
add address=205.188.161.4 list=conficker
add address=221.7.91.31 list=conficker

Kemudian buat rule di ip firewall filter untuk “menangkap akses” dari client ke ip-ip conficker berdasarkan address-list di atas:

/ip firewall filter
add chain=forward action=add-src-to-address-list dst-address-list=conficker address-list=src-conficker \
address-list-timeout=3d comment="ADD to address-list src-conficker"

Penulis buat timeout untuk 3 hari. Taruh filter ini di baris sebelum baris forward atau jump forward:

/ip firewall filter print

54 ;;; ADD src-add to conficker
chain=forward action=add-src-to-address-list dst-address-list=conficker \
address-list=src-conficker address-list-timeout=3d
55 chain=forward action=jump jump-target=tcp protocol=tcp
56 chain=forward action=jump jump-target=udp protocol=udp
57 chain=forward action=jump jump-target=icmp protocol=icmp

Setelah beberapa jam. berikut tampilan ip firewall address-list:
list ip client yang akses ke ip conficker

Mengenali akses ke ip conficker di router linux
Untuk mengenali akses ke ip-ip conficker di linux, kita buat langkah-langkah sebagai berikut:

1. Buat list ip coficker yang telah diperoleh dari cara di atas di /etc/conficker/ip.conficker.

$ cat /etc/conficker/ip.conficker
64.70.19.33
66.90.81.140
72.167.51.186
74.208.46.216
74.208.64.145
83.68.16.6
97.74.200.45
143.215.143.11
149.20.56.32
199.2.137.252
205.188.161.4
221.7.91.31

2. Buat script iptables.conficker.sh untuk menandai akses ke ip conficker.
view source
print?
#!/bin/sh
LAN_IFACE="eth0"
IPTABLES="/usr/sbin/iptables"
FIPCONFICKER="/etc/conficker/ip.conficker"
while read IPCONFICKER
do
# uncomment 2 baris di bawah untuk blok akses ke ip conficker untuk kernel 2.6
#$IPTABLES -t nat -I PREROUTING -i $LAN_IFACE -d $IPCONFICKER -j DROP \
# -m comment –comment "IP Conficker"
# uncomment 1 baris di bawah untuk blok akses ke ip conficker untuk kernel 2.4
#$IPTABLES -t nat -I PREROUTING -i $LAN_IFACE -d $IPCONFICKER -j DROP
# log akses ke ip conficker dan simpan ke /var/log/syslog
$IPTABLES -t nat -I PREROUTING -i $LAN_IFACE -d $IPCONFICKER -m limit \
–limit 1/hour –limit-burst 1 -j LOG –log-prefix "CONFICKER " –log-ip-options
done <$FIPCONFICKER
3. Jalankan scriptnya sh iptables.conficker.sh
4. Untuk melihat client yang akses ke ip conficker.

$ sudo grep 'CONFICKER ' /var/log/syslog|cut -f1,2,3,10,11 -d' '
Dec 21 16:21:23 SRC=192.168.0.252 DST=221.7.91.31

Terakhir, beritahu client agar cek PC windows apakah benar-benar terkena virus conficker dengan mengunjungi alamat http://www.confickerworkinggroup.org/infection_test/cfeyechart.html

Hasil tangkapan log dari salah satu warnet A:

Dec 22 14:40:34 SRC=192.168.0.19 DST=143.215.143.11
Dec 22 14:40:34 SRC=192.168.0.19 DST=205.188.161.4
Dec 22 14:40:34 SRC=192.168.0.19 DST=97.74.200.45
Dec 22 14:40:34 SRC=192.168.0.19 DST=83.68.16.6
Dec 22 14:40:35 SRC=192.168.0.19 DST=199.2.137.252
Dec 22 14:40:42 SRC=192.168.0.19 DST=221.7.91.31
Dec 22 14:40:49 SRC=192.168.0.19 DST=149.20.56.32
Dec 22 14:40:50 SRC=192.168.0.19 DST=74.208.64.145
Dec 22 22:08:58 SRC=192.168.0.19 DST=74.208.64.145
Dec 22 22:08:58 SRC=192.168.0.19 DST=199.2.137.252
Dec 22 22:08:58 SRC=192.168.0.19 DST=221.7.91.31
Dec 22 22:09:06 SRC=192.168.0.19 DST=205.188.161.4
Dec 22 22:09:06 SRC=192.168.0.19 DST=143.215.143.11
Dec 22 22:09:13 SRC=192.168.0.19 DST=83.68.16.6
Dec 22 22:09:13 SRC=192.168.0.19 DST=97.74.200.45
Dec 22 22:09:21 SRC=192.168.0.19 DST=149.20.56.32

Apa kesimpulan anda ?

source :awarmanf.wordpress.com

DHCP Client and Server


General Information
Summary
The DHCP (Dynamic Host Configuration Protocol) is needed for easy distribution of IP addresses in a network. The MikroTik RouterOS implementation includes both server and client parts and is compliant with RFC2131.
General usage of DHCP:
• IP assignment in LAN, cable-modem, and wireless systems
• Obtaining IP settings on cable-modem systems
IP addresses can be bound to MAC addresses using static lease feature.
DHCP server can be used with MikroTik RouterOS HotSpot feature to authenticate and account DHCP clients. See the HotSpot Manual for more information.
Quick Setup Guide
This example will show you how to setup DHCP-Server and DHCP-Client on MikroTik RouterOS.
• Setup of a DHCP Server:
1. Create an IP address pool
/ip pool add name=dhcp-pool ranges=172.16.0.10-172.16.0.20
2. Add a DHCP network which will concern to the network 172.16.0.0/12 and will distribute a gateway with IP address 172.16.0.1 to DHCP clients:
/ip dhcp-server network add address=172.16.0.0/12 gateway=172.16.0.1
3. Finally, add a DHCP server:
/ip dhcp-server add interface=wlan1 address-pool=dhcp-pool
• Setup of a DHCP Client (which will get a lease from the DHCP server, configured above).
1. Add the DHCP client:
2. /ip dhcp-client add interface=wlan1 use-peer-dns=yes \
add-default-route=yes disabled=no
3. Check whether you have obtained a lease:
4. [admin@Server] ip dhcp-client> print detail
5. Flags: X – disabled, I – invalid
6. 0 interface=wlan1 add-default-route=yes use-peer-dns=yes status=bound
7. address=172.16.0.20/12 gateway=172.16.0.1 dhcp-server=192.168.0.1
8. primary-dns=159.148.147.194 expires-after=2d23:58:52
[admin@Server] ip dhcp-client>
Specifications
Packages required: dhcp
License required: Level1
Submenu level: /ip dhcp-client, /ip dhcp-server, /ip dhcp-relay
Standards and Technologies: DHCP
Description
The DHCP protocol gives and allocates IP addresses to IP clients. DHCP is insecure by design and should only be used in trusted networks. DHCP server always listens on UDP 67 port, DHCP client – on UDP 68 port. The initial negotiation involves communication between broadcast addresses (on some phases sender will use source address of 0.0.0.0 and/or destination address of 255.255.255.255). You should be aware of this when building firewall.
Additional Resources
• ISC Dynamic Host Configuration Protocol (DHCP)
• DHCP mini-HOWTO
• ISC DHCP FAQ
DHCP Client Setup
Submenu level: /ip dhcp-client
Description
The MikroTik RouterOS DHCP client may be enabled on any Ethernet-like interface. There can only be one active DHCP client per interface. The client will accept an address, netmask, default gateway, two DNS server addresses and two NTP server addresses. All other information is ignored. The received IP address with the respective netmask will be added to the corresponding interface. The default gateway will be added to the routing table as a dynamic entry. Should the DHCP client be disabled or not renew an address, the dynamic default route will be removed. If there is already a default route installed prior the DHCP client obtains one, the route obtained by the DHCP client will be shown as invalid.
Property Description
add-default-route (yes | no; default: yes) – whether to add the default route to the gateway specified by the DHCP server
address (read-only: IP address/netmask) – IP address and netmask, which is assigned to DHCP Client from the Server
client-id (text) – corresponds to the settings suggested by the network administrator or ISP. Commonly it is set to the client’s MAC address, but it may as well be any text string
dhcp-server (read-only: IP address) – IP address of the DHCP server
expires-after (read-only: time) – time, when the lease expires (specified by the DHCP server)
gateway (read-only: IP address) – IP address of the gateway which is assigned by DHCP server
host-name (text) – the host name of the client as sent to a DHCP server
interface (name) – any Ethernet-like interface (this includes wireless and EoIP tunnels) on which the client searches for a DHCP server
primary-dns (read-only: IP address) – IP address of the primary DNS server, assigned by the DHCP server
primary-ntp (read-only: IP address) – IP address of the primary NTP server, assigned by the DHCP server
secondary-dns (read-only: IP address) – IP address of the secondary DNS server, assigned by the DHCP server
secondary-ntp (read-only: IP address) – IP address of the secondary NTP server, assigned by the DHCP server
status (read-only: bound | error | rebinding… | renewing… | requesting… | searching… | stopped) – shows the status of DHCP slient
use-peer-dns (yes | no; default: yes) – whether to accept the DNS settings advertized by DHCP server (they will override the settings put in the /ip dns submenu)
use-peer-ntp (yes | no; default: yes) – whether to accept the NTP settings advertized by DHCP server (they will override the settings put in the /system ntp client submenu)
Command Description
release – release current binding and restart DHCP client
renew – renew current leases. If the renew operation was not successful, client tries to reinitialize lease (i.e. it starts lease request procedure (rebind) as if it had not received an IP address yet)
Notes
If host-name property is not specified, client’s system identity will be sent in the respective field of DHCP request.
If client-id property is not specified, client’s MAC address will be sent in the respective field of DHCP request.
If use-peer-dns property is enabled, the DHCP client will unconditionally rewrite the settings in /ip dns submenu. In case two or more DNS servers were received, first two of them are set as primary and secondary servers respectively. In case one DNS server was received, it is put as primary server, and the secondary server is left intact.
Example
To add a DHCP client on ether1 interface:
/ip dhcp-client add interface=ether1 disabled=no
[admin@MikroTik] ip dhcp-client> print detail
Flags: X – disabled, I – invalid
0 interface=ether1 add-default-route=yes use-peer-dns=yes use-peer-ntp=yes
status=bound address=192.168.0.65/24 gateway=192.168.0.1
dhcp-server=192.168.0.1 primary-dns=192.168.0.1 primary-ntp=192.168.0.1
expires-after=9m44s
[admin@MikroTik] ip dhcp-client>

DHCP Server Setup
Submenu level: /ip dhcp-server
Description
The router supports an individual server for each Ethernet-like interface. The MikroTik RouterOS DHCP server supports the basic functions of giving each requesting client an IP address/netmask lease, default gateway, domain name, DNS-server(s) and WINS-server(s) (for Windows clients) information (set up in the DHCP networks submenu)
In order DHCP server to work, you must set up also IP pools (do not include the DHCP server’s own IP address into the pool range) and DHCP networks.
It is also possible to hand out leases for DHCP clients using the RADIUS server, here are listed the parameters for used in RADIUS server.
Access-Request:
• NAS-Identifier – router identity
• NAS-IP-Address – IP address of the router itself
• NAS-Port – unique session ID
• NAS-Port-Type – Ethernet
• Calling-Station-Id – client identifier (active-client-id)
• Framed-IP-Address – IP address of the client (active-address)
• Called-Station-Id – name of DHCP server
• User-Name – MAC address of the client (active-mac-address)
• Password – “”
Access-Accept:
• Framed-IP-Address – IP address that will be assigned to client
• Framed-Pool – ip pool from which to assign ip address to client
• Rate-Limit – Datarate limitation for DHCP clients. Format is: rx-rate[/tx-rate] [rx-burst-rate[/tx-burst-rate] [rx-burst-threshold[/tx-burst-threshold] [rx-burst-time[/tx-burst-time][priority] [rx-rate-min[/tx-rate-min]]]]. All rates should be numbers with optional ‘k’ (1,000s) or ‘M’ (1,000,000s). If tx-rate is not specified, rx-rate is as tx-rate too. Same goes for tx-burst-rate and tx-burst-threshold and tx-burst-time. If both rx-burst-threshold and tx-burst-threshold are not specified (but burst-rate is specified), rx-rate and tx-rate are used as burst thresholds. If both rx-burst-time and tx-burst-time are not specified, 1s is used as default. Priority takes values 1..8, where 1 implies the highest priority, but 8 – the lowest. If rx-rate-min and tx-rate-min are not specified rx-rate and tx-rate values are used. The rx-rate-min and tx-rate-min values can not exceed rx-rate and tx-rate values.
• Ascend-Data-Rate – tx/rx data rate limitation if multiple attributes are provided, first limits tx data rate, second – rx data rate. If used together with Ascend-Xmit-Rate, specifies rx rate. 0 if unlimited
• Ascend-Xmit-Rate – tx data rate limitation. It may be used to specify tx limit only instead of sending two sequental Ascend-Data-Rate attributes (in that case Ascend-Data-Rate will specify the receive rate). 0 if unlimited
• Session-Timeout – max lease time (lease-time)
Property Description
add-arp (yes | no; default: no) – whether to add dynamic ARP entry:
no – either ARP mode should be enabled on that interface or static ARP entries should be administratively defined in /ip arp submenu
address-pool (name | static-only; default: static-only) – IP pool, from which to take IP addresses for clients
static-only – allow only the clients that have a static lease (i.e. no dynamic addresses will be given to clients, only the ones added in lease submenu)
always-broadcast (yes | no; default: no) – always send replies as broadcasts
authoritative (after-10sec-delay | after-2sec-delay | no | yes; default: after-2sec-delay) – whether the DHCP server is the only one DHCP server for the network
after-10sec-delay – to clients request for an address, dhcp server will wait 10 seconds and if there is another request from the client after this period of time, then dhcp server will offer the address to the client or will send DHCPNAK, if the requested address is not available from this server
after-2sec-delay – to clients request for an address, dhcp server will wait 2 seconds and if there is another request from the client after this period of time, then dhcp server will offer the address to the client or will send DHCPNAK, if the requested address is not available from this server
no – dhcp server ignores clients requests for addresses that are not available from this server
yes – to clients request for an address that is not available from this server, dhcp server will send negative acknowledgment (DHCPNAK)
bootp-support (none | static | dynamic; default: static) – support for BOOTP clients
none – do not respond to BOOTP requests
static – offer only static leases to BOOTP clients
dynamic – offer static and dynamic leases for BOOTP clients
delay-threshold (time; default: none) – if secs field in DHCP packet is smaller than delay-threshold, then this packet is ignored
none – there is no threshold (all DHCP packets are processed)
interface (name) – Ethernet-like interface name
lease-time (time; default: 72h) – the time that a client may use the assigned address. The client will try to renew this address after a half of this time and will request a new address after time limit expires
name (name) – reference name
relay (IP address; default: 0.0.0.0) – the IP address of the relay this DHCP server should process requests from:
0.0.0.0 – the DHCP server will be used only for direct requests from clients (no DHCP really allowed)
255.255.255.255 – the DHCP server should be used for any incomming request from a DHCP relay except for those, which are processed by another DHCP server that exists in the /ip dhcp-server submenu
src-address (IP address; default: 0.0.0.0) – the address which the DHCP client must send requests to in order to renew an IP address lease. If there is only one static address on the DHCP server interface and the source-address is left as 0.0.0.0, then the static address will be used. If there are multiple addresses on the interface, an address in the same subnet as the range of given addresses should be used
use-radius (yes | no; default: no) – whether to use RADIUS server for dynamic leases
Notes
Client will only receive a DHCP lease in case it is directly reachable by its MAC address through that interface (some wireless bridges may change client’s MAC address).
If authoritative property is set to yes, the DHCP server is sending rejects for the leases it cannot bind or renew. It also may (although not always) help to prevent the network users to run their own DHCP servers illicitly, disturbing the proper way the network should be functioning.
If relay property of a DHCP server is not set to 0.0.0.0 the DHCP server will not respond to the direct requests from clients.
Example
To add a DHCP server to interface ether1, lending IP addresses from dhcp-clients IP pool for 2 hours:
/ip dhcp-server add name=dhcp-office disabled=no address-pool=dhcp-clients \
interface=ether1 lease-time=2h
[admin@MikroTik] ip dhcp-server> print
Flags: X – disabled, I – invalid
# NAME INTERFACE RELAY ADDRESS-POOL LEASE-TIME ADD-ARP
0 dhcp-office ether1 dhcp-clients 02:00:00
[admin@MikroTik] ip dhcp-server>

Store Leases on Disk
Submenu level: /ip dhcp-server config
Description
Leases are always stored on disk on graceful shutdown and reboot. If they would be saved on disk on every lease change, a lot of disk writes would happen. There are no problems if it happens on a hard drive, but is very bad for Compact Flash (especially, if lease times are very short). To minimize writes on disk, all changes are saved on disk every store-leases-disk seconds. If this time will be very short (immediately), then no changes will be lost even in case of hard reboots and power losts. But, on CF there may be too many writes in case of short lease times (as in case of hotspot). If this time will be very long (never), then there will be no writes on disk, but information about active leases may be lost in case of power loss. In these cases dhcp server may give out the same ip address to another client, if first one will not respond to ping requests.
Property Description
store-leases-disk (time-interval | immediately | never; default: 5min) – how frequently lease changes should be stored on disk
DHCP Networks
Submenu level: /ip dhcp-server network
Property Description
address (IP address/netmask) – the network DHCP server(s) will lend addresses from
boot-file-name (text) – Boot file name
dhcp-option (text) – add additional DHCP options from /ip dhcp-server option list. You cannot redefine parameters which are already defined in this submenu:
Subnet-Mask (code 1) – netmask
Router (code 3) – gateway
Domain-Server (code 6) – dns-server
Domain-Name (code 15) – domain
NTP-Servers (code 42) – ntp-server
NETBIOS-Name-Server (code 44) – wins-server
dns-server (text) – the DHCP client will use these as the default DNS servers. Two comma-separated DNS servers can be specified to be used by DHCP client as primary and secondary DNS servers
domain (text) – the DHCP client will use this as the ‘DNS domain’ setting for the network adapter
gateway (IP address; default: 0.0.0.0) – the default gateway to be used by DHCP clients
netmask (integer: 0..32; default: 0) – the actual network mask to be used by DHCP client
0 – netmask from network address is to be used
next-server (IP address) – IP address of next server to use in bootstrap
ntp-server (text) – the DHCP client will use these as the default NTP servers. Two comma-separated NTP servers can be specified to be used by DHCP client as primary and secondary NTP servers
wins-server (text) – the Windows DHCP client will use these as the default WINS servers. Two comma-separated WINS servers can be specified to be used by DHCP client as primary and secondary WINS servers
Notes
The address field uses netmask to specify the range of addresses the given entry is valid for. The actual netmask clients will be using is specified in netmask property.
DHCP Server Leases
Submenu level: /ip dhcp-server lease
Description
DHCP server lease submenu is used to monitor and manage server’s leases. The issued leases are showed here as dynamic entries. You can also add static leases to issue a particular client (identified by MAC address) the desired IP address.
Generally, the DHCP lease it allocated as follows:
1. an unused lease is in waiting state
2. if a client asks for an IP address, the server chooses one
3. if the client will receive statically assigned address, the lease becomes offered, and then bound with the respective lease time
4. if the client will receive a dynamic address (taken from an IP address pool), the router sends a ping packet and waits for answer for 0.5 seconds. During this time, the lease is marked testing
5. in case, the address does not respond, the lease becomes offered, and then bound with the respective lease time
6. in other case, the lease becomes busy for the lease time (there is a command to retest all busy addresses), and the client’s request remains unanswered (the client will try again shortly)
A client may free the leased address. The dynamic lease is removed, and the allocated address is returned to the address pool. But the static lease becomes busy until the client will reacquire the address.
Note that the IP addresses assigned statically are not probed.
Property Description
active-address (read-only: IP address) – actual IP address for this lease
active-client-id (read-only: text) – actual client-id of the client
active-mac-address (read-only: MAC address) – actual MAC address of the client
active-server (read-only: list) – actual dhcp server, which serves this client
address (IP address) – specify ip address (or ip pool) for static lease
0.0.0.0 – use pool from server
agent-circuit-id (read-only: text) – circuit ID of DHCP relay agent
agent-remote-id (read-only: text) – Remote ID, set by DHCP relay agent
always-broadcast (yes | no) – send all repies as broadcasts
block-access (yes | no; default: no) – block access for this client (drop packets from this client)
blocked (read-only: flag) – whether the lease is blocked
client-id (text; default: “”) – if specified, must match DHCP ‘client identifier’ option of the request
expires-after (read-only: time) – time until lease expires
host-name (read-only: text) – shows host name option from last received DHCP request
lease-time (time; default: 0s) – time that the client may use the address
0s – lease will never expire
mac-address (MAC address; default: 00:00:00:00:00:00) – if specified, must match the MAC address of the client
radius (read-only: yes | no) – shows, whether this dynamic lease is authenticated by RADIUS or not
rate-limit (read-only: text; default: “”) – sets rate limit for active lease. Format is: rx-rate[/tx-rate] [rx-burst-rate[/tx-burst-rate] [rx-burst-threshold[/tx-burst-threshold] [rx-burst-time[/tx-burst-time]]]]. All rates should be numbers with optional ‘k’ (1,000s) or ‘M’ (1,000,000s). If tx-rate is not specified, rx-rate is as tx-rate too. Same goes for tx-burst-rate and tx-burst-threshold and tx-burst-time. If both rx-burst-threshold and tx-burst-threshold are not specified (but burst-rate is specified), rx-rate and tx-rate is used as burst thresholds. If both rx-burst-time and tx-burst-time are not specified, 1s is used as default
server (read-only: name) – server name which serves this client
src-mac-address (MAC address) – source MAC address
status (read-only: waiting | testing | authorizing | busy | offered | bound) – lease status:
waiting – not used static lease
testing – testing whether this address is used or not (only for dynamic leases) by pinging it with timeout of 0.5s
authorizing – waiting for response from radius server
busy – this address is assigned statically to a client or already exists in the network, so it can not be leased
offered – server has offered this lease to a client, but did not receive confirmation from the client
bound – server has received client’s confirmation that it accepts offered address, it is using it now and will free the address not later, than the lease time will be over
use-src-mac (MAC address) – use this source MAC address instead
Command Description
check-status – check status of a given busy dynamic lease, and free it in case of no response
make-static – convert a dynamic lease to a static one
Notes
If rate-limit is specified, a simple queue is added with corresponding parameters when lease enters bound state. Arp entry is added right after adding of queue is done (only if add-arp is enabled for dhcp server). To be sure, that client cannot use his ip address without getting dhcp lease and thus avoiding rate-limit, reply-only mode must be used on that ethernet interface.
Even though client address may be changed (with adding a new item) in lease print list, it will not change for the client. It is true for any changes in the DHCP server configuration because of the nature of the DHCP protocol. Client tries to renew assigned IP address only when half a lease time is past (it tries to renew several times). Only when full lease time is past and IP address was not renewed, new lease is asked (rebind operation).
the deault mac-address value will never work! You should specify a correct MAC address there.
Example
To assign 10.5.2.100 static IP address for the existing DHCP client (shown in the lease table as item #0):
[admin@MikroTik] ip dhcp-server lease> print
Flags: X – disabled, R – radius, D – dynamic, B – blocked
# ADDRESS MAC-ADDRESS HOST-NAME SERVER RATE-LIMIT STATUS
0 D 10.5.2.90 00:04:EA:C6:0E:40 switch bound
1 D 10.5.2.91 00:04:EA:99:63:C0 switch bound
[admin@MikroTik] ip dhcp-server lease> add copy-from=0 address=10.5.2.100
[admin@MikroTik] ip dhcp-server lease> print
Flags: X – disabled, R – radius, D – dynamic, B – blocked
# ADDRESS MAC-ADDRESS HOST-NAME SERVER RATE-LIMIT STATUS
0 D 10.5.2.91 00:04:EA:99:63:C0 switch bound
1 10.5.2.100 00:04:EA:C6:0E:40 switch bound
[admin@MikroTik] ip dhcp-server lease>

DHCP Alert
Submenu level: /ip dhcp-server alert
Description
To find any rogue DHCP servers as soon as they appear in your network, DHCP Alert tool can be used. It will monitor ethernet for all DHCP replies and check, whether this reply comes from a valid DHCP server. If reply from unknown DHCP server is detected, alert gets triggered:
[admin@MikroTik] ip dhcp-server alert>/log print
00:34:23 dhcp,critical,error,warning,info,debug dhcp alert on Public:
discovered unknown dhcp server, mac 00:02:29:60:36:E7, ip 10.5.8.236
[admin@MikroTik] ip dhcp-server alert>
When the system alerts about a rogue DHCP server, it can execute a custom script.
As DHCP replies can be unicast, rogue dhcp detector may not receive any offer to other dhcp clients at all. To deal with this, rogue dhcp detector acts as a dhcp client as well – it sends out dhcp discover requests once a minute
Property Description
alert-timeout (none/time; default: none) – time, after which alert will be forgotten. If after that time the same server will be detected, new alert will be generated
none – infinite time
interface (name) – interface, on which to run rogue DHCP server finder
on-alert (text) – script to run, when an unknown DHCP server is detected
unknown-server (read-only: text) – list of MAC addresses of detected unknown DHCP servers. Server is removed from this list after alert-timeout
valid-server (text) – list of MAC addresses of valid DHCP servers
Notes
All alerts on an interface can be cleared at any time using command: /ip dhcp-server alert reset-alert
Note, that e-mail can be sent, using /system logging action add target=email
DHCP Option
Submenu level: /ip dhcp-server option
Description
With help of DHCP Option list, it is possible to define additional custom options for DHCP Server to advertise.
Property Description
code (integer: 1..254) – dhcp option code. All codes are available at http://www.iana.org/assignments/bootp-dhcp-parameters
name (name) – descriptive name of the option
value (text) – parameter’s value in form of a string. If the string begins with “0x”, it is assumed as a hexadecimal value
Notes
The defined options you can use in /ip dhcp-server network submenu
According to the DHCP protocol, a parameter is returned to the DHCP client only if it requests this parameter, specifying the respective code in DHCP request Parameter-List (code 55) attribute. If the code is not included in Parameter-List attribute, DHCP server will not send it to the DHCP client.
Example
This example shows how to set DHCP server to reply on DHCP client’s Hostname request (code 12) with value Host-A.
Add an option named Option-Hostname with code 12 (Hostname) and value Host-A:
[admin@MikroTik] ip dhcp-server option> add name=Hostname code=12 \
value=”Host-A”
[admin@MikroTik] ip dhcp-server option> print
# NAME CODE VALUE
0 Option-Hostname 12 Host-A
[admin@MikroTik] ip dhcp-server option>
Use this option in DHCP server network list:
[admin@MikroTik] ip dhcp-server network> add address=10.1.0.0/24 \
\… gateway=10.1.0.1 dhcp-option=Option-Hostname dns-server=159.148.60.20
[admin@MikroTik] ip dhcp-server network> print detail
0 address=10.1.0.0/24 gateway=10.1.0.1 dns-server=159.148.60.20
dhcp-option=Option-Hostname
[admin@MikroTik] ip dhcp-server network>
Now the DHCP server will reply with its Hostname Host-A to DHCP client (if requested)
DHCP Relay
Submenu level: /ip dhcp-relay
Description
DHCP Relay is just a proxy that is able to receive a DHCP request and resend it to the real DHCP server
Property Description
delay-threshold (time; default: none) – if secs field in DHCP packet is smaller than delay-threshold, then this packet is ignored
dhcp-server (text) – list of DHCP servers’ IP addresses which should the DHCP requests be forwarded to
interface (name) – interface name the DHCP relay will be working on
local-address (IP address; default: 0.0.0.0) – the unique IP address of this DHCP relay needed for DHCP server to distinguish relays:
0.0.0.0 – the IP address will be chosen automatically
name (name) – descriptive name for relay
Notes
DHCP relay does not choose the particular DHCP server in the dhcp-server list, it just send the incoming request to all the listed servers.
Example
To add a DHCP relay named relay on ether1 interface resending all received requests to the 10.0.0.1 DHCP server:
[admin@MikroTik] ip dhcp-relay> add name=relay interface=ether1 \
\… dhcp-server=10.0.0.1 disabled=no
[admin@MikroTik] ip dhcp-relay> print
Flags: X – disabled, I – invalid
# NAME INTERFACE DHCP-SERVER LOCAL-ADDRESS
0 relay ether1 10.0.0.1 0.0.0.0

[admin@MikroTik] ip dhcp-relay>

Question&Answer-Based Setup
Command name: /ip dhcp-server setup
Questions
addresses to give out (text) – the pool of IP addresses DHCP server should lease to the clients
dhcp address space (IP address/netmask; default: 192.168.0.0/24) – network the DHCP server will lease to the clients
dhcp relay (IP address; default: 0.0.0.0) – the IP address of the DHCP relay between the DHCP server and the DHCP clients
dhcp server interface (name) – interface to run DHCP server on
dns servers (IP address) – IP address of the appropriate DNS server to be propagated to the DHCP clients
gateway (IP address; default: 0.0.0.0) – the default gateway of the leased network
lease time (time; default: 3d) – the time the lease will be valid
Notes
Depending on current settings and answers to the previous questions, default values of following questions may be different. Some questions may disappear if they become redundant (for example, there is no use of asking for ‘relay’ when the server will lend the directly connected network)
Example
To configure DHCP server on ether1 interface to lend addresses from 10.0.0.2 to 10.0.0.254 which belong to the 10.0.0.0/24 network with 10.0.0.1 gateway and 159.148.60.2 DNS server for the time of 3 days:
[admin@MikroTik] ip dhcp-server> setup
Select interface to run DHCP server on

dhcp server interface: ether1
Select network for DHCP addresses

dhcp address space: 10.0.0.0/24
Select gateway for given network

gateway for dhcp network: 10.0.0.1
Select pool of ip addresses given out by DHCP server

addresses to give out: 10.0.0.2-10.0.0.254
Select DNS servers

dns servers: 159.148.60.20
Select lease time

lease time: 3d
[admin@MikroTik] ip dhcp-server>

The wizard has made the following configuration based on the answers above:
[admin@MikroTik] ip dhcp-server> print
Flags: X – disabled, I – invalid
# NAME INTERFACE RELAY ADDRESS-POOL LEASE-TIME ADD-ARP
0 dhcp1 ether1 0.0.0.0 dhcp_pool1 3d no

[admin@MikroTik] ip dhcp-server> network print
# ADDRESS GATEWAY DNS-SERVER WINS-SERVER DOMAIN
0 10.0.0.0/24 10.0.0.1 159.148.60.20

[admin@MikroTik] ip dhcp-server> /ip pool print
# NAME RANGES
0 dhcp_pool1 10.0.0.2-10.0.0.254

[admin@MikroTik] ip dhcp-server>

Application Examples
Dynamic Addressing, using DHCP-Relay
Let us consider that you have several IP networks ‘behind’ other routers, but you want to keep all DHCP servers on a single router. To do this, you need a DHCP relay on your network which relies DHCP requests from clients to DHCP server.
This example will show you how to configure a DHCP server and a DHCP relay which serve 2 IP networks – 192.168.1.0/24 and 192.168.2.0/24 that are behind a router DHCP-Relay.

IP addresses of DHCP-Server:
[admin@DHCP-Server] ip address> print
Flags: X – disabled, I – invalid, D – dynamic
# ADDRESS NETWORK BROADCAST INTERFACE
0 192.168.0.1/24 192.168.0.0 192.168.0.255 To-DHCP-Relay
1 10.1.0.2/24 10.1.0.0 10.1.0.255 Public
[admin@DHCP-Server] ip address>
IP addresses of DHCP-Relay:
[admin@DHCP-Relay] ip address> print
Flags: X – disabled, I – invalid, D – dynamic
# ADDRESS NETWORK BROADCAST INTERFACE
0 192.168.0.1/24 192.168.0.0 192.168.0.255 To-DHCP-Server
1 192.168.1.1/24 192.168.1.0 192.168.1.255 Local1
2 192.168.2.1/24 192.168.2.0 192.168.2.255 Local2
[admin@DHCP-Relay] ip address>
To setup 2 DHCP Servers on DHCP-Server router add 2 pools. For networks 192.168.1.0/24 and 192.168.2.0:
/ip pool add name=Local1-Pool ranges=192.168.1.11-192.168.1.100
/ip pool add name=Local1-Pool ranges=192.168.2.11-192.168.2.100
[admin@DHCP-Server] ip pool> print
# NAME RANGES
0 Local1-Pool 192.168.1.11-192.168.1.100
1 Local2-Pool 192.168.2.11-192.168.2.100
[admin@DHCP-Server] ip pool>
Create DHCP Servers:
/ip dhcp-server add interface=To-DHCP-Relay relay=192.168.1.1 \
address-pool=Local1-Pool name=DHCP-1 disabled=no
/ip dhcp-server add interface=To-DHCP-Relay relay=192.168.2.1 \
address-pool=Local2-Pool name=DHCP-2 disabled=no
[admin@DHCP-Server] ip dhcp-server> print
Flags: X – disabled, I – invalid
# NAME INTERFACE RELAY ADDRESS-POOL LEASE-TIME ADD-ARP
0 DHCP-1 To-DHCP-Relay 192.168.1.1 Local1-Pool 3d00:00:00
1 DHCP-2 To-DHCP-Relay 192.168.2.1 Local2-Pool 3d00:00:00
[admin@DHCP-Server] ip dhcp-server>
Configure respective networks:
/ip dhcp-server network add address=192.168.1.0/24 gateway=192.168.1.1 \
dns-server=159.148.60.20
/ip dhcp-server network add address=192.168.2.0/24 gateway=192.168.2.1 \
dns-server 159.148.60.20
[admin@DHCP-Server] ip dhcp-server network> print
# ADDRESS GATEWAY DNS-SERVER WINS-SERVER DOMAIN
0 192.168.1.0/24 192.168.1.1 159.148.60.20
1 192.168.2.0/24 192.168.2.1 159.148.60.20
[admin@DHCP-Server] ip dhcp-server network>
Configuration of DHCP-Server is done. Now let’s configure DHCP-Relay:
/ip dhcp-relay add name=Local1-Relay interface=Local1 \
dhcp-server=192.168.0.1 local-address=192.168.1.1 disabled=no
/ip dhcp-relay add name=Local2-Relay interface=Local2 \
dhcp-server=192.168.0.1 local-address=192.168.2.1 disabled=no
[admin@DHCP-Relay] ip dhcp-relay> print
Flags: X – disabled, I – invalid
# NAME INTERFACE DHCP-SERVER LOCAL-ADDRESS
0 Local1-Relay Local1 192.168.0.1 192.168.1.1
1 Local2-Relay Local2 192.168.0.1 192.168.2.1
[admin@DHCP-Relay] ip dhcp-relay>
IP Address assignment, using FreeRADIUS Server
Let us consider that we want to assign IP addresses for clients, using the RADIUS server.

We assume that you already have installed FreeRADIUS. Just add these lines to specified files:
users file:
00:0B:6B:31:02:4B Auth-Type := Local, Password == “”
Framed-IP-Address = 192.168.0.55
clients.conf file
client 172.16.0.1 {
secret = MySecret
shortname = Server
}
Configure Radius Client on RouterOS:
/radius add service=dhcp address=172.16.0.2 secret=MySecret
[admin@DHCP-Server] radius> print detail
Flags: X – disabled
0 service=dhcp called-id=”” domain=”” address=172.16.0.2 secret=”MySecret”
authentication-port=1812 accounting-port=1813 timeout=00:00:00.300
accounting-backup=no realm=””
[admin@DHCP-Server] radius>
Setup DHCP Server:
1. Create an address pool:
/ip pool add name=Radius-Clients ranges=192.168.0.11-192.168.0.100
2. Add a DHCP server:
3. /ip dhcp-server add address-pool=Radius-Clients use-radius=yes interface=Local \
disabled=no
4. Configure DHCP networks:
5. /ip dhcp-server network add address=192.168.0.0/24 gateway=192.168.0.1 \
dns-server=159.148.147.194,159.148.60.20
Now the client with MAC address 00:0B:6B:31:02:4B will always receive IP address 192.168.0.55.
© Copyright 1999-2007, MikroTik. All rights reserved. Mikrotik, RouterOS and RouterBOARD are trademarks of Mikrotikls SIA. Other trademarks and registered trademarks mentioned herein are properties of their respective owners.
Home >
Documentation >
V3.0 >
DNS Client and Cache
PDF version

DNS Client and Cache
Document revision: 1.3 (November 28, 2007, 10:44 GMT)
Applies to: V3.0
General Information
Summary
DNS cache is used to minimize DNS requests to an external DNS server as well as to minimize DNS resolution time. This is a simple recursive DNS server with local items.
Specifications
Packages required: system
License required: Level1
Submenu level: /ip dns
Standards and Technologies: DNS
Hardware usage: Not significant
Description
A MikroTik router with DNS feature enabled can be set as a DNS server for any DNS-compliant client. Moreover, MikroTik router can be specified as a primary DNS server under its dhcp-server settings. When the remote requests are enabled, the MikroTik router responds to TCP and UDP DNS requests on port 53.
Additional Resources
http://www.freesoft.org/CIE/Course/Section2/3.htm
http://www.networksorcery.com/enp/protocol/dns.htm
• RFC1035
DNS Cache Setup
Submenu level: /ip dns
Description
DNS facility is used to provide domain name resolution for router itself as well as for the clients connected to it.
Property Description
allow-remote-requests (yes | no; default: no) – specifies whether to allow network requests
cache-max-ttl (time; default: 1w) – specifies maximum time-to-live for cache records. In other words, cache records will expire unconditionally after cache-max-ttl time. Shorter TTL received from DNS servers are respected
cache-size (integer: 512..10240; default: 2048KiB) – specifies the size of DNS cache in KiB
cache-used (read-only: integer) – displays the current cache size in KiB
primary-dns (IP address; default: 0.0.0.0) – primary DNS server
secondary-dns (IP address; default: 0.0.0.0) – secondary DNS server
Notes
If the property use-peer-dns under /ip dhcp-client is set to yes then primary-dns under /ip dns will change to a DNS address given by DHCP Server.
Example
To set 159.148.60.2 as the primary DNS server and allow the router to be used as a DNS server, do the following:
[admin@MikroTik] ip dns> set primary-dns=159.148.60.2 \
\… allow-remote-requests=yes
[admin@MikroTik] ip dns> print
primary-dns: 159.148.60.2
secondary-dns: 0.0.0.0
allow-remote-requests: yes
cache-size: 2048KiB
cache-max-ttl: 1w
cache-used: 7KiB
[admin@MikroTik] ip dns>
Cache Monitoring
Submenu level: /ip dns cache
Description
This menu provides a list with all address (DNS type “A”) records stored on the server
Property Description
address (read-only: IP address) – IP address of the host
name (read-only: name) – DNS name of the host
ttl (read-only: time) – remaining time-to-live for the record
All DNS Entries
Submenu level: /ip dns cache all
Description
This menu provides a complete list with all DNS records stored on the server
Property Description
data (read-only: text) – DNS data field. IP address for type “A” records. Other record types may have different contents of the data field (like hostname or arbitrary text)
name (read-only: name) – DNS name of the host
ttl (read-only: time) – remaining time-to-live for the record
type (read-only: text) – DNS record type
Static DNS Entries
Submenu level: /ip dns static
Description
The MikroTik RouterOS has an embedded DNS server feature in DNS cache. It allows you to link the particular domain names with the respective IP addresses and advertize these links to the DNS clients using the router as their DNS server. This feature can also be used to provide fake DNS information to your network clients. For example, resolving any DNS request for a certain set of domains (or for the whole Internet) to your own page.
The server is capable of resolving DNS requests based on POSIX basic regular expressions, so that multiple requets can be matched with the same entry. In case an entry does not conform with DNS naming standards, it is considered a regular expression and marked with ‘R’ flag. The list is ordered and is checked from top to bottom. Regular expressions are checked first, then the plain records.
Property Description
address (IP address) – IP address to resolve domain name with
name (text) – DNS name to be resolved to a given IP address. May be a regular expression
ttl (time) – time-to-live of the DNS record
Notes
Reverse DNS lookup (Address to Name) of the regular expression entries is not possible. You can, however, add an additional plain record with the same IP address and specify some name for it.
Remember that the meaning of a dot (.) in regular expressions is any character, so the expression should be escaped properly. For example, if you need to match anything within example.com domain but not all the domains that just end with example.com, like http://www.another-example.com, use name=”.*\\.example\\.com”
Regular expression matching is significantly slower than of the plain entries, so it is advised to minimize the number of regular expression rules and optimize the expressions themselves.
Example
To add a static DNS entry for http://www.example.com to be resolved to 10.0.0.1 IP address:
[admin@MikroTik] ip dns static> add name http://www.example.com address=10.0.0.1
[admin@MikroTik] ip dns static> print
Flags: D – dynamic, X – disabled, R – regexp
# NAME ADDRESS TTL
0 http://www.example.com 10.0.0.1 1d
[admin@MikroTik] ip dns static>
Flushing DNS cache
Command name: /ip dns cache flush
Command Description
flush – clears internal DNS cache
Example
[admin@MikroTik] ip dns> cache flush
[admin@MikroTik] ip dns> print
primary-dns: 159.148.60.2
secondary-dns: 0.0.0.0
allow-remote-requests: yes
cache-size: 2048 KiB
cache-max-ttl: 1w
cache-used: 10 KiB
[admin@MikroTik] ip dns>
© Copyright 1999-2007, MikroTik. All rights reserved. Mikrotik, RouterOS and RouterBOARD are trademarks of Mikrotikls SIA. Other trademarks and registered trademarks mentioned herein are properties of their respective owners.
Home >
Documentation >
V3.0 >
HotSpot Gateway
PDF version

HotSpot Gateway
Document revision: 4.3 (January 14, 2008, 8:59 GMT)
Applies to: V3.0
General Information
Summary
The MikroTik HotSpot Gateway enables providing of public network access for clients using wireless or wired network connections.
HotSpot Gateway features:
• authentication of clients using local client database, or RADIUS server
• accounting using local database, or RADIUS server
• Walled-garden system (accessing some web pages without authorization)
Quick Setup Guide
Given a router with two interfaces: Local (where HotSpot clients are connected to) and Public, which is connected to the Internet. To set up HotSpot on the Local interface:
1. first, a valid IP configuration is required on both interfaces. This can be done with /setup command or by setting up the router manually. In this example we will assume the configuration with DHCP server already enabled on the Local interface
2. valid DNS configuration must be set up in the /ip dns submenu
3. To put HotSpot on the Local interface, using the same IP address pool as DHCP server uses for that interface: /ip hotspot add interface=local address-pool=dhcp-pool-1
4. and finally, add at least one HotSpot user: /ip hotspot user add name=admin
These simple steps should be sufficient to enable HotSpot system
Please find HotSpot How-to’s, which will answer most of your questions about configuring a HotSpot gateway, at the end of this manual. It is still recommended that you read and understand all the Description section below before deploying a HotSpot system.
If this does not work:
• check that /ip dns contains valid DNS servers, try to /ping http://www.example.com to see, that DNS resolving works
• make sure that connection tracking is enabled: /ip firewall connection tracking set enabled=yes
Specifications
Packages required: hotspot, dhcp(optional)
License required: Level1 (Limited to 1 active user) , Level3 (Limited to 1 active user) , Level4 (Limited to 200 active users) , Level5 (Limited to 500 active users) , Level6
Submenu level: /ip hotspot
Standards and Technologies: ICMP, DHCP
Hardware usage: Not significant
Description
MikroTik HotSpot Gateway should have at least two network interfaces:
1. HotSpot interface, which is used to connect HotSpot clients
2. LAN/WAN interface, which is used to access network resources. For example, DNS and RADIUS server(s) should be accessible
The diagram below shows a sample HotSpot setup.

The HotSpot interface should have an IP address assigned to it. Physical network connection has to be established between the HotSpot user’s computer and the gateway. It can be wireless (the wireless card should be registered to AP), or wired (the NIC card should be connected to a hub or a switch).
Introduction to HotSpot
HotSpot is a way to authorize users to access some network resources. It does not provide traffic encryption. To log in, users may use almost any web browser (either HTTP or HTTPS protocol), so they are not required to install additional software. The gateway is accounting the uptime and amount of traffic each of its clients have used, and also can send this information to a RADIUS server. The HotSpot system may limit each particular user’s bitrate, total amount of traffic, uptime and some other parameters to be mentioned further in this document.
The HotSpot system is targeted to provide authentication within a local network (for the local network users to access the Internet), but may as well be used to authorize access from outer networks to access local resources (like an authentication gateway for the outside world to access your network). Configuring Walled Garden feature, it is possible to allow users to access some web pages without the need of prior authentication.
Getting Address
First of all, a client must get an IP address. It may be set on the client statically, or leased from a DHCP server. The DHCP server may provide ways of binding lent IP addresses to clients MAC addresses, if required. The HotSpot system does not care how did a client get an address before he/she gets to the HotSpot login page.
Moreover, HotSpot server may automatically and transparently change any IP address (yes, meaning really any IP address) of a client to a valid unused address from the selected IP pool. If a user is able to get his/her Internet connection working at their place, he/she will be able to get his/her connection working in the HotSpot network. This feature gives a possibility to provide a network access (for example, Internet access) to mobile clients that are not willing (or are disallowed, not qualified enough or otherwise unable) to change their networking settings. The users will not notice the translation (i.e., there will not be any changes in the users’ config), but the router itself will see completely different (from what is actually set on each client) source IP addresses on packets sent from the clients (even the firewall mangle table will ‘see’ the translated addresses). This technique is called one-to-one NAT, but is also known as “Universal Client” as that is how it was called in the RouterOS version 2.8.
One-to-one NAT accepts any incoming address from a connected network interface and performs a network address translation so that data may be routed through standard IP networks. Clients may use any preconfigured addresses. If the one-to-one NAT feature is set to translate a client’s address to a public IP address, then the client may even run a server or any other service that requires a public IP address. This NAT is changing source address of each packet just after it is received by the router (it is like source NAT that is performed early in the packet path, so that even firewall mangle table, which normally ‘sees’ received packets unaltered, can only ‘see’ the translated address).
Note also that arp mode must be enabled on the interface you use one-to-one NAT on.
Before the authentication
When enabling HotSpot on an interface, the system automatically sets up everything needed to show login page for all clients that are not logged in. This is done by adding dynamic destination NAT rules, which you can observe on a working HotSpot system. These rules are needed to redirect all HTTP and HTTPS requests from unauthorized users to the HotSpot authentication proxy. Other rules that are also inserted, will be described later in a special section of this manual.
In most common setup, opening any HTTP page will bring up the HotSpot servlet login page (which can be customized extensively, as described later on). As normal user behavior is to open web pages by their DNS names, a valid DNS configuration should be set up on the HotSpot gateway itself (it is possible to reconfigure the gateway so that it will not require local DNS configuration, but such a configuration is impractical and thus not recommended).
Walled Garden
You may wish not to require authorization for some services (for example to let clients access the web server of your company without registration), or even to require authorization only to a number of services (for example, for users to be allowed to access an internal file server or another restricted area). This can be done by setting up Walled Garden system.
When a not logged-in user requests a service allowed in the Walled Garden configuration, the HotSpot gateway does not intercept it, or in case of HTTP, simply redirects the request to the original destination. Other requests are redirected to the HotSpot servlet (login page infrastructure). When a user is logged in, there is no effect of this table on him/her.
Walled Garden for HTTP requests is using the embedded proxy server (/ip proxy). This means that all the configured parameters of that proy server will also be effective for the WalledGarden clients (as well as for all clients that have transparent proxy enabled)
Authentication
There are currently 6 different authentication methods. You can use one or more of them simultaneously:
• HTTP PAP – simplest method, which shows the HotSpot login page and expect to get the authentication info (i.e. username and password) in plain text. Note that passwords are not being encrypted when transferred over the network. Another use of this method is the possibility of hard-coded authentication information in the servlet’s login page simply creating the appropriate link.
• HTTP CHAP – standard method, which includes CHAP challenge in the login page. The CHAP MD5 hash challenge is to be used together with the user’s password for computing the string which will be sent to the HotSpot gateway. The hash result (as a password) together with username is sent over network to HotSpot service (so, password is never sent in plain text over IP network). On the client side, MD5 algorithm is implemented in JavaScript applet, so if a browser does not support JavaScript (like, for example, Internet Explorer 2.0 or some PDA browsers) or it has JavaScipt disabled, it will not be able to authenticate users. It is possible to allow unencrypted passwords to be accepted by turning on HTTP PAP authentication method, but it is not recommended (due to security considerations) to use that feature.
• HTTPS – the same as HTTP PAP, but using SSL protocol for encrypting transmissions. HotSpot user just send his/her password without additional hashing (note that there is no need to worry about plain-text password exposure over the network, as the transmission itself is encrypted). In either case, HTTP POST method (if not possible, then – HTTP GET method) is used to send data to the HotSpot gateway.
• HTTP cookie – after each successful login, a cookie is sent to the web browser and the same cookie is added to active HTTP cookie list. Next time the same user will try to log in, web browser will send the saved HTTP cookie. This cookie will be compared with the one stored on the HotSpot gateway and only if source MAC address and randomly generated ID match the ones stored on the gateway, user will be automatically logged in using the login information (username and password pair) was used when the cookie was first generated. Otherwise, the user will be prompted to log in, and in the case authentication is successful, old cookie will be removed from the local HotSpot active cookie list and the new one with different random ID and expiration time will be added to the list and sent to the web browser. It is also possible to erase cookie on user manual logoff (not in the default server pages, but you can modify them to perform this). This method may only be used together with HTTP PAP, HTTP CHAP or HTTPS methods as there would be nothing to generate cookies in the first place otherwise.
• MAC address – try to authenticate clients as soon as they appear in the hosts list (i.e., as soon as they have sent any packet to the HotSpot server), using client’s MAC address as username.
• Trial – users may be allowed to use the service free of charge for some period of time for evaluation, and be required to authenticate only after this period is over. HotSpot can be configured to allow some amount of time per MAC address to be freely used with some limitations imposed by the provided user profile. In case the MAC address still has some trial time unused, the login page will contain the link for trial login. The time is automatically reset after the configured amount of time (so that, for example, any MAC address may use 30 minutes a day without ever registering). The username of such a user (as seen in the active user table and in the login link) is “T-XX:XX:XX:XX:XX:XX” (where XX:XX:XX:XX:XX:XX is his/her MAC address). The authentication procedure will not ask RADIUS server permission to authorise such a user.
HotSpot can authenticate users consulting the local user database or a RADIUS server (local database is consulted first, then – a RADIUS server). In case of HTTP cookie authentication via RADIUS server, the router will send the same information to the server as was used when the cookie was first generated. If authentication is done locally, profile corresponding to that user is used, otherwise (in case RADIUS reply did not contain the group for that user) the default profile is used to set default values for parameters, which are not set in RADIUS access-accept message. For more information on how the interaction with a RADIUS server works, see the respective manual section.
The HTTP PAP method also makes it possible to authenticate by requesting the page /login?username=username&password=password . In case you want to log in using telnet connection, the exact HTTP request would look like that: GET /login?username=username&password=password HTTP/1.0 (note that the request is case-sensitive)
Authorization
After authentication, user gets access to the Internet, and receives some limitations (which are user profile specific). HotSpot may also perform a one-to-one NAT for the client, so that a particular user would always receive the same IP address regardless of what PC is he/she working at.
The system will automatically detect and redirect requests to a proxy server a client is using (if any; it may be set in his/her settings to use an unknown to us proxy server) to the proxy server embedded in the router.
Authorization may be delegated to a RADIUS server, which delivers similar configuration options as the local database. For any user requiring authorization, a RADIUS server gets queried first, and if no reply received, the local database is examined. RADIUS server may send a Change of Authorization request according to standards to alter the previously accepted parameters.
Advertisement
The same proxy used for unauthorized clients to provide Walled-Garden facility, may also be used for authorized users to show them advertisement popups. Transparent proxy for authorized users allows to monitor http requests of the clients and to take some action if required. It enables the possibility to open status page even if client is logged in by mac address, as well as to show advertisements time after time
When the time has come to show an advertisement, the server redirects client’s web browser to the status page. Only requests, which provide html content, are redirected (images and other content will not be affected). The status page displays the advertisement and next advertise-interval is used to schedule next advertisement. If status page is unable to display an advertisement for configured timeout starting from moment, when it is scheduled to be shown, client access is blocked within walled-garden (just as unauthorized clients are). Client is unblocked when the scheduled page is finally shown. Note that if popup windows are blocked in the browser, the link on the status page may be used to open the advertisement manually.
While client is blocked, FTP and other services will not be allowed. Thus requiring client to open an advertisement for any Internet activity not especially allowed by the Walled-Garden.
Accounting
The HotSpot system implement accounting internally, you are not required to do anything special for it to work. The accounting information for each user may be sent to a RADIUS server.
Configuration menus
• /ip hotspot – HotSpot servers on particular interfaces (one server per interface). HotSpot server must be added in this menu in order for HotSpot system to work on an interface
• /ip hotspot profile – HotSpot server profiles. Settings, which affect login procedure for HotSpot clients are configured here. More than one HotSpot servers may use the same profile
• /ip hotspot host – dynamic list of active network hosts on all HotSpot interfaces. Here you can also find IP address bindings of the one-to-one NAT
• /ip hotspot ip-binding – rules for binding IP addresses to hosts on hotspot interfaces
• /ip hotspot service-port – address translation helpers for the one-to-one NAT
• /ip hotspot walled-garden – Walled Garden rules at HTTP level (DNS names, HTTP request substrings)
• /ip hotspot walled-garden ip – Walled Garden rules at IP level (IP addresses, IP protocols)
• /ip hotspot user – local HotSpot system users
• /ip hotspot user profile – local HotSpot system users profiles (user groups)
• /ip hotspot active – dynamic list of all authenticated HotSpot users
• /ip hotspot cookie – dynamic list of all valid HTTP cookies
Question&Answer-Based Setup
Command name: /ip hotspot setup
Questions
address pool of network (name) – IP address pool for the HotSpot network
dns name (text) – DNS domain name of the HotSpot gateway (will be statically configured on the local DNS proxy
dns servers (IP address,[IP address]) – DNS servers for HotSpot clients
hotspot interface (name) – interface to run HotSpot on
ip address of smtp server (IP address; default: 0.0.0.0) – IP address of the SMTP server to redirect SMTP requests (TCP port 25) to
• 0.0.0.0 – no redirect
local address of network (IP address; default: 10.5.50.1/24) – HotSpot gateway address for the interface
masquerade network (yes | no; default: yes) – whether to masquerade the HotSpot network
name of local hotspot user (text; default: admin) – username of one automatically created user
passphrase (text) – the passphrase of the certificate you are importing
password for the user (text) – password for the automatically created user
select certificate (name | none import-other-certificate) – choose SSL certificate from the list of the imported certificates
• none – do not use SSL
• import-other-certificate – setup the certificates not imported yet, and ask this question again
Notes
Depending on current settings and answers to the previous questions, default values of following questions may be different. Some questions may disappear if they become redundant
Example
To configure HotSpot on ether1 interface (which is already configured with address of 192.0.2.1/25), and adding user admin with password rubbish:
[admin@MikroTik] > ip hotspot setup
hotspot interface: ether1
local address of network: 192.0.2.1/24
masquerade network: yes
address pool of network: 192.0.2.2-192.0.2.126
select certificate: none
ip address of smtp server: 0.0.0.0
dns servers: 192.0.2.254
dns name: hs.example.net
name of local hotspot user: admin
password for the user: rubbish
[admin@MikroTik] >

HotSpot Interface Setup
Submenu level: /ip hotspot
Description
HotSpot system is put on individual interfaces. You can run completely different HotSpot configurations on different interfaces
Property Description
HTTPS (read-only: flag) – whether the HTTPS service is actually running on the interface (i.e., it is set up in the server profile, and a valid certificate is imported in the router)
address-pool (name | none; default: none) – IP address pool name for performing one-to-one NAT. You can choose not to use the one-to-one NAT
none – do not perform one-to-one NAT for the clients of this HotSpot interface
addresses-per-mac (integer | unlimited; default: 2) – number of IP addresses allowed to be bind with any particular MAC address (it is a small chance to reduce denial of service attack based on taking over all free IP addresses in the address pool). Not available if address-pool is set to none
unlimited – number of IP addresses per one MAC address is not limited
idle-timeout (time | none; default: 00:05:00) – idle timeout (maximal period of inactivity) for unauthorized clients. It is used to detect, that client is not using outer networks (e.g. Internet), i.e., there is NO TRAFFIC coming from that client and going through the router. Reaching the timeout, user will be dropped of the host list, and the address used buy the user will be freed
none – do not timeout idle users
interface (name) – interface to run HotSpot on
ip-of-dns-name (read-only: IP address) – IP address of the HotSpot gateway’s DNS name set in the HotSpot interface profile
keepalive-timeout (time | none; default: none) – keepalive timeout for unauthorized clients. Used to detect, that the computer of the client is alive and reachable. If check will fail during this period, user will be dropped of the host list, and the address used buy the user will be freed
none – do not timeout unreachable users
profile (name; default: default) – default HotSpot profile for the interface
Command Description
reset-html (name) – overwrite the existing HotSpot servlet with the original HTML files. It is used if you have changed the servlet and it is not working after that
Notes
addresses-per-mac property works only if address pool is defined. Also note that in case you are authenticating users connected through a router, than all the IP addresses will seem to have come from one MAC address.
Example
To add HotSpot system to the local interface, allowing the system to do one-to-one NAT for each client (addresses from the HS-real address pool will be used for the NAT):
[admin@MikroTik] ip hotspot> add interface=local address-pool=HS-real
[admin@MikroTik] ip hotspot> print
Flags: X – disabled, I – invalid, S – HTTPS
# NAME INTERFACE ADDRESS-POOL PROFILE IDLE-TIMEOUT
0 hs-local local HS-real default 00:05:00
[admin@MikroTik] ip hotspot>

HotSpot Server Profiles
Submenu level: /ip hotspot profile
Description
There may be various different HotSpot systems, defined as HotSpot Server Profiles, on the same gateway machine. One or more interfaces can be grouped into one server profile. There are very few settings for the servers on particular interfaces – most of the configuration is set in the server profiles. For example, it is possible to make completely different set of servlet pages for each server profile, and define different RADIUS servers for authentication.
Property Description
dns-name (text) – DNS name of the HotSpot server. This is the DNS name used as the name of the HotSpot server (i.e., it appears as the location of the login page). This name will automatically be added as a static DNS entry in the DNS cache
hotspot-address (IP address; default: 0.0.0.0) – IP address for HotSpot service
html-directory (text; default: hotspot) – name of the directory (accessible with FTP), which stores the HTML servlet pages (when changed, the default pages are automatically copied into specified directory if it does not exist already)
http-cookie-lifetime (time; default: 3d) – validity time of HTTP cookies
http-proxy (IP address; default: 0.0.0.0) – address of the proxy server the HotSpot service will use as a [parent] proxy server for all those requests intercepted by Universal Proxy system and not defined in the /ip proxy direct list. If not specified, the address defined in parent-proxy parameter of /ip proxy. If that is absent as well, the request will be resolved by the local proxy
login-by (multiple choice: cookie | http-chap | http-pap | https | mac | trial; default: cookie,http-chap) – which authentication methods to use
cookie – use HTTP cookies to authenticate, without asking user credentials. Other method will be used in case the client does not have cookie, or the stored username and password pair are not valid anymore since the last authentication. May only be used together with other HTTP authentication methods (HTTP-PAP, HTTP-CHAP or HTTPS), as in the other case there would be no way for the cookies to be generated in the first place
http-chap – use CHAP challenge-response method with MD5 hashing algorithm for hashing passwords. This way it is possible to avoid sending clear-text passwords over an insecure network. This is the default authentication method
http-pap – use plain-text authentication over the network. Please note that in case this method will be used, your user passwords will be exposed on the local networks, so it will be possible to intercept them
https – use encrypted SSL tunnel to transfer user communications with the HotSpot server. Note that in order this to work, a valid certificate must be imported into the router (see a separate manual on certificate management)
mac – try to use client’s MAC address first as its username. If the matching MAC address exists in the local user database or on the RADIUS server, the client will be authenticated without asking to fill the login form
trial – does not require authentication for a certain amount of time
mac-auth-password (text) – if MAC authentication is used, this field can be used to specify password for the users to be authenticated by their MAC addresses
nas-port-type (text; default: wireless-802.11) – NAS-Port-Type attribute value to be sent to the RADIUS server
radius-accounting (yes | no; default: yes) – whether to send RADIUS server accounting information on each user once in a while (the “while” is defined in the radius-interim-update property)
radius-default-domain (text; default: “”) – default domain to use for RADIUS requests. It allows to select different RADIUS servers depending on HotSpot server profile, but may be handful for single RADIUS server as well.
radius-interim-update (time | received; default: received) – how often to sent cumulative accounting reports.
0s – same as received
received – use whatever value received from the RADIUS server
radius-location-id (text) – Raduis-Location-Id attribute value to be sent to the RADIUS server
radius-location-name (text) – Raduis-Location-Name attribute value to be sent to the RADIUS server
rate-limit (text; default: “”) – Rate limitation in form of rx-rate[/tx-rate] [rx-burst-rate[/tx-burst-rate] [rx-burst-threshold[/tx-burst-threshold] [rx-burst-time[/tx-burst-time]]]] [priority] [rx-rate-min[/tx-rate-min]] from the point of view of the router (so “rx” is client upload, and “tx” is client download). All rates should be numbers with optional ‘k’ (1,000s) or ‘M’ (1,000,000s). If tx-rate is not specified, rx-rate is as tx-rate too. Same goes for tx-burst-rate and tx-burst-threshold and tx-burst-time. If both rx-burst-threshold and tx-burst-threshold are not specified (but burst-rate is specified), rx-rate and tx-rate is used as burst thresholds. If both rx-burst-time and tx-burst-time are not specified, 1s is used as default. rx-rate-min and tx-rate min are the values of limit-at properties
smtp-server (IP address; default: 0.0.0.0) – default SMTP server to be used to redirect unconditionally all user SMTP requests to
split-user-domain (yes | no; default: no) – whether to split username from domain name when the username is given in “user@domain” or in “domain\user” format
ssl-certificate (name | none; default: none) – name of the SSL certificate to use for HTTPS authentication. Not used for other authentication methods
trial-uptime (time/time; default: 30m/1d) – is used only when authentication method is trial. Specifies the amount of time the user identified by MAC address can use HotSpot services without authentication and the time, that has to pass that the user is allowed to use HotSpot services again
trial-user-profile (name; default: default) – is used only only when authentication method is trial. Specifies user profile, that trial users will use
use-radius (yes | no; default: no) – whether to use RADIUS to authenticate HotSpot users
Notes
If dns-name property is not specified, hotspot-address is used instead. If hotspot-address is also absent, then both are to be detected automatically.
In order to use RADIUS authentication, the /radius menu must be set up properly.
Trial authentication method should always be used together with one of the other authentication methods.
Example
HotSpot User Profiles
Submenu level: /ip hotspot user profile
Description
Article moved to: HotSpot AAA section
HotSpot Users
Submenu level: /ip hotspot user
Description
Article moved to: HotSpot AAA section
HotSpot Active Users
Submenu level: /ip hotspot active
Description
Article moved to: HotSpot AAA section
HotSpot Cookies
Submenu level: /ip hotspot cookie
Description
Cookies can be used for authentication in the Hotspot service
Property Description
domain (read-only: text) – domain name (if split from username)
expires-in (read-only: time) – how long is the cookie valid
mac-address (read-only: MAC address) – user’s MAC address
user (read-only: name) – username
Notes
There can be multiple cookies with the same MAC address. For example, there will be a separate cookie for each web browser on the same computer.
Cookies can expire – that’s the way how it is supposed to be. Default validity time for cookies is 3 days (72 hours), but it can be changed for each individual HotSpot server profile, for example :
/ip hotspot profile set default http-cookie-lifetime=1d
Example
To get the list of valid cookies:
[admin@MikroTik] ip hotspot cookie> print
# USER DOMAIN MAC-ADDRESS EXPIRES-IN
0 ex 01:23:45:67:89:AB 23h54m16s
[admin@MikroTik] ip hotspot cookie>

HTTP-level Walled Garden
Submenu level: /ip hotspot walled-garden
Description
Walled garden is a system which allows unauthorized use of some resources, but requires authorization to access other resources. This is useful, for example, to give access to some general information about HotSpot service provider or billing options.
This menu only manages Walled Garden for HTTP and HTTPS protocols. Other protocols can also be included in Walled Garden, but that is configured elsewhere (in /ip hotspot walled-garden ip; see the next section of this manual for details)
Property Description
action (allow | deny; default: allow) – action to undertake if a request matches the rule:
allow – allow the access to the page without prior authorization
deny – authorization is required to access this page
dst-address (read-only: IP address) – IP address of the destination web server (installed by IP-level walled garden)
dst-host (wildcard; default: “”) – domain name of the destination web server
dst-port (integer; default: “”) – the TCP port a client has send the request to
hits (read-only: integer) – how many times has this rule been used
method (text) – HTTP method of the request
path (wildcard; default: “”) – the path of the request
server (name) – name of the HotSpot server this rule applies to
src-address (IP address) – IP address of the user sending the request
Notes
Wildcard properties (dst-host and dst-path) match a complete string (i.e., they will not match “example.com” if they are set to “example”). Available wildcards are ‘*’ (match any number of any characters) and ‘?’ (match any one character). Regular expressions are also accepted here, but for property to be treated as a regular expression, it should start with a colon (‘:’).
Small hits in using regular expressions:
• \\ symbol sequence is used to enter \ character in console
• \. pattern means . only (in regular expressions single dot in pattern means any symbol)
• to show that no symbols are allowed before the given pattern, we use ^ symbol at the beginning of the pattern
• to specify that no symbols are allowed after the given pattern, we use $ symbol at the end of the pattern
You can not use path property for HTTPS requests as router can not (and should not – that is what the HTTPS protocol was made for!) decrypt the request.
IP-level walled garden, described in the following section, makes dynamic entries here. In this case, the dst-address property is filled (it is empty otherwise).
Example
To allow unauthorized requests to the http://www.example.com domain’s /paynow.html page:
[admin@MikroTik] ip hotspot walled-garden> add path=”/paynow.html” \
\… dst-host=”www.example.com”
[admin@MikroTik] ip hotspot walled-garden> print detail
Flags: X – disabled, D – dynamic
0 dst-host=”www.example.com” path=”/paynow.html” action=allow
[admin@MikroTik] ip hotspot walled-garden>

IP-level Walled Garden
Submenu level: /ip hotspot walled-garden ip
Description
This menu is manages Walled Garden for generic IP requests. See the previous section for managing HTTP and HTTPS protocol specific properties (like the actual DNS name, HTTP method and path used in requests).
Property Description
action (accept | drop | reject; default: accept) – action to undertake if a packet matches the rule:
accept – allow the access to the page without prior authorization
drop – the authorization is required to access this page
reject – the authorization is required to access this page, in case the page will be accsessed withot authorization ICMP reject message host-unreachable will be generated
dst-address (IP address) – IP address of the destination web server
dst-host (text; default: “”) – domain name of the destination web server (this is not a regular expression or a wildcard of any kind). The DNS name specified is resolved to a list of IP addresses when the rule is added, and all those IP addresses are used
dst-port (integer; default: “”) – the TCP or UDP port (protocol MUST be specified explicitly in the protocol property) a client has send the request to
protocol (integer | ddp egp encap ggp gre hmp icmp idpr-cmtp igmp ipencap ipip ipsec-ah ipsec-esp iso-tp4 ospf pup rdp rspf st tcp udp vmtp xns-idp xtp) – IP protocol name
server (name) – name of the HotSpot server this rule applied to
src-address (IP address) – IP address of the user sending the request
Example
One-to-one NAT static address bindings
Submenu level: /ip hotspot ip-binding
Description
You can setup NAT translations statically based on either the original IP address (or IP network), or the original MAC address. You can also allow some addresses to bypass HotSpot authentication (i.e., they will be able work without having to log in to the network first) and completely block some addresses.
Property Description
address (IP address / [netmask]; default: “”) – the original IP address or network of the client
mac-address (MAC address; default: “”) – the source MAC address of the client
server (name|all; default: all) – the name of the server the client is connecting to
to-address (IP address; default: “”) – IP address to translate the original client address to. If address property is given as network, this is the starting address for the translation (i.e., the first address is translated to to-address, address + 1 to to-address + 1, and so on)
type (regular | bypassed | blocked) – type of the static binding entry
regular – perform a one-to-one NAT translation according to the values set in this entry
bypassed – perform the translation, but exclude the client from having to log in to the HotSpot system
blocked – the translation will not be preformed, and all packets from the host will be dropped
Notes
This is an ordered list, so you can put more specific entries on the top of the list for them to override more common rules that appear lower. You can even put an entry with 0.0.0.0/0 address at the end of the list to make the desired action default for those addresses that will not match any other entry.
Active Host List
Submenu level: /ip hotspot host
Description
This menu shows all active network hosts that are connected to the HotSpot gateway. This list includes all one-to-one NAT translations
Property Description
address (read-only: IP address) – the original IP address of the client
authorized (read-only: flag) – whether the client is successfully authenticated by the HotSpot system
bridge-port (read-only: name) – the actual physical interface, which the host is connected to. This is used when HotSpot service is put on a bridge interface to determine the host’s actual port within the bridge.
bypassed (read-only: flag) – whether the client does not need to be authorized by the HotSpot system
bytes-in (read-only: integer) – how many bytes did the router receive from the client
bytes-out (read-only: integer) – how many bytes did the router send to the client
found-by (read-only: text) – how was this host discovered (first packet type, sender, recipient)
host-dead-time (read-only: time) – how long has the router not received any packets (including ARP replies, keepalive replies and user traffic) from this host
idle-time (read-only: time) – the amount of time has the user been idle
idle-timeout (read-only: time) – the exact value of idle-timeout that applies to this user. This property shows how long should the user stay idle for it to be logged off automatically
keepalive-timeout (read-only: time) – the exact value of keepalive-timeout that applies to this user. This property shows how long should the user’s computer stay out of reach for it to be logged off automatically
mac-address (read-only: MAC address) – the actual MAC address of the user
packets-in (read-only: integer) – how many packets did the router receive from the client
packets-out (read-only: integer) – how many packets did the router send to the client
server (read-only: name) – name of the server, which the host is connected to
static (read-only: flag) – whether this translation has been taken from the static IP binding list
to-address (read-only: IP address) – what address is the original IP address of the host translated to
uptime (read-only: time) – current session time of the user (i.e., how long has the user been in the active host list)
Command Description
make-binding – copy a dynamic entry from this list to the static IP bindings list
Input Parameters
unnamed (name) – item number
comment (text) – custom comment to the static entry to be created
type (regular | bypassed | blocked) – the type of the static entry
Service Port
Submenu level: /ip hotspot service-port
Description
Just like for classic NAT, the HotSpot embedded one-to-one NAT ‘breaks’ some protocols that are incompatible with address translation. To leave these protocols consistent, helper modules must be used. For the one-to-one NAT the only such a module is for FTP protocol.
Property Description
name (read-only: name) – protocol name
ports (read-only: integer) – list of the ports on which the protocol is working
Example
To set the FTP protocol uses both 20 and 21 TCP port:
[admin@MikroTik] ip hotspot service-port> print
Flags: X – disabled
# NAME PORTS
0 ftp 21
[admin@MikroTik] ip hotspot service-port> set ftp ports=20,21
[admin@MikroTik] ip hotspot service-port> print
Flags: X – disabled
# NAME PORTS
0 ftp 20
21
[admin@MikroTik] ip hotspot service-port>

Customizing HotSpot: Firewall Section
Description
Apart from the obvious dynamic entries in the /ip hotspot submenu itself (like hosts and active users), some additional rules are added in the firewall tables when activating a HotSpot service. Unlike RouterOS version 2.8, there are relatively few firewall rules added in the firewall as the main job is made by the one-to-one NAT algorithm.
NAT rules
From /ip firewall nat print dynamic command, you can get something like this (comments follow after each of the rules):
0 D chain=dstnat action=jump jump-target=hotspot hotspot=from-client

Putting all HotSpot-related tasks for packets from all HotSpot clients into a separate chain.
1 I chain=hotspot action=jump jump-target=pre-hotspot

Any actions that should be done before HotSpot rules apply, should be put in the pre-hotspot chain. This chain is under full administrator control and does not contain any rules set by the system, hence the invalid jump rule (as the chain does not have any rules by default).
2 D chain=hotspot action=redirect to-ports=64872 dst-port=53 protocol=udp
3 D chain=hotspot action=redirect to-ports=64872 dst-port=53 protocol=tcp

Redirect all DNS requests to the HotSpot service. The 64872 port provides DNS service for all HotSpot users. If you want HotSpot server to listen also to another port, add rules here the same way, changing dst-port property.
4 D chain=hotspot action=redirect to-ports=64873 hotspot=local-dst dst-port=80
protocol=tcp

Redirect all HTTP login requests to the HTTP login servlet. The 64873 is HotSpot HTTP servlet port.
5 D chain=hotspot action=redirect to-ports=64875 hotspot=local-dst dst-port=443
protocol=tcp

Redirect all HTTPS login requests to the HTTPS login servlet. The 64875 is HotSpot HTTPS servlet port.
6 D chain=hotspot action=jump jump-target=hs-unauth hotspot=!auth protocol=tcp

All other packets except DNS and login requests from unauthorized clients should pass through the hs-unauth chain.
7 D chain=hotspot action=jump jump-target=hs-auth hotspot=auth protocol=tcp

And packets from the authorized clients – through the hs-auth chain.
8 D ;;; http://www.mikrotik.com
chain=hs-unauth action=return dst-address=66.228.113.26 dst-port=80 protocol=tcp

First in the hs-unauth chain is put everything that affects TCP protocol in the /ip hotspot walled-garden ip submenu (i.e., everything where either protocol is not set, or set to TCP). Here we are excluding http://www.mikrotik.com from being redirected to the login page.
9 D chain=hs-unauth action=redirect to-ports=64874 dst-port=80 protocol=tcp

All other HTTP requests are redirected to the Walled Garden proxy server which listens the 64874 port. If there is an allow entry in the /ip hotspot walled-garden menu for an HTTP request, it is being forwarded to the destination. Otherwise, the request will be automatically redirected to the HotSpot login servlet (port 64873).
10 D chain=hs-unauth action=redirect to-ports=64874 dst-port=3128 protocol=tcp
11 D chain=hs-unauth action=redirect to-ports=64874 dst-port=8080 protocol=tcp

HotSpot by default assumes that only these ports may be used for HTTP proxy requests. These two entries are used to “catch” client requests to unknown proxies (you can add more rules here for other ports). I.e., to make it possible for the clients with unknown proxy settings to work with the HotSpot system. This feature is called “Universal Proxy”. If it is detected that a client is using some proxy server, the system will automatically mark that packets with the http hotspot mark to work around the unknown proxy problem, as we will see later on. Note that the port used (64874) is the same as for HTTP requests in the rule #9 (so both HTTP and HTTP proxy requests are processed by the same code).
12 D chain=hs-unauth action=redirect to-ports=64875 dst-port=443 protocol=tcp

HTTPS proxy is listening on the 64875 port.
13 I chain=hs-unauth action=jump jump-target=hs-smtp dst-port=25 protocol=tcp

Redirect for SMTP protocol may also be defined in the HotSpot configuration. In case it is, a redirect rule will be put in the hs-smtp chain. This is done so that users with unknown SMTP configuration would be able to send their mail through the service provider’s (your) SMTP server instead of going to the [possibly unavailable outside their network of origin] SMTP server users have configured on their computers. The chain is empty by default, hence the invalid jump rule.
14 D chain=hs-auth action=redirect to-ports=64874 hotspot=http protocol=tcp

Providing HTTP proxy service for authorized users. Authenticated user requests may need to be subject to transparent proxying (the “Universal Proxy” technique and advertisement feature). This http mark is put automatically on the HTTP proxy requests to the servers detected by the HotSpot HTTP proxy (the one that is listening on the 64874 port) as HTTP proxy requests for unknown proxy servers. This is done so that users that have some proxy settings would use the HotSpot gateway instead of the [possibly unavailable outside their network of origin] proxy server users have configured in their computers. This mark is also applied when advertisement is due to be shown to the user, as well as on any HTTP requests done form the users whose profile is configured to transparently proxy their requests.
15 I chain=hs-auth action=jump jump-target=hs-smtp dst-port=25 protocol=tcp

Providing SMTP proxy for authorized users (the same as in rule #13).
Packet filter rules
From /ip firewall filter print dynamic command, you can get something like this (comments follow after each of the rules):
0 D chain=forward action=jump jump-target=hs-unauth hotspot=from-client,!auth

Any packet that traverse the router from an unauthorized client will be sent to the hs-unauth chain. The hs-unauth implements the IP-based Walled Garden filter.
1 D chain=forward action=jump jump-target=hs-unauth-to hotspot=to-client,!auth

Everything that comes to clients through the router, gets redirected to another chain, called hs-unauth-to. This chain should reject unauthorized requests to the clients.
2 D chain=input action=jump jump-target=hs-input hotspot=from-client

Everything that comes from clients to the router itself, gets to yet another chain, called hs-input.
3 I chain=hs-input action=jump jump-target=pre-hs-input

Before proceeding with [predefined] dynamic rules, the packet gets to the administratively controlled pre-hs-input chain, which is empty by default, hence the invalid state of the jump rule.
4 D chain=hs-input action=accept dst-port=64872 protocol=udp
5 D chain=hs-input action=accept dst-port=64872-64875 protocol=tcp

Allow client access to the local authentication and proxy services (as described earlier).
6 D chain=hs-input action=jump jump-target=hs-unauth hotspot=!auth

All other traffic from unauthorized clients to the router itself will be treated the same way as the traffic traversing the routers.
7 D chain=hs-unauth action=return protocol=icmp
8 D ;;; http://www.mikrotik.com
chain=hs-unauth action=return dst-address=66.228.113.26 dst-port=80 protocol=tcp

Unlike NAT table where only TCP-protocol related Walled Garden entries were added, in the packet filter hs-unauth chain is added everything you have set in the /ip hotspot walled-garden ip menu. That is why although you have seen only one entry in the NAT table, there are two rules here.
9 D chain=hs-unauth action=reject reject-with=tcp-reset protocol=tcp
10 D chain=hs-unauth action=reject reject-with=icmp-net-prohibited

Everything else that has not been while-listed by the Walled Garden will be rejected. Note usage of TCP Reset for rejecting TCP connections.
11 D chain=hs-unauth-to action=return protocol=icmp
12 D ;;; http://www.mikrotik.com
chain=hs-unauth-to action=return src-address=66.228.113.26 src-port=80 protocol=tcp

Same action as in rules #7 and #8 is performed for the packets destined to the clients (chain hs-unauth-to) as well.
13 D chain=hs-unauth-to action=reject reject-with=icmp-host-prohibited

Reject all packets to the clients with ICMP reject message.
Customizing HotSpot: HTTP Servlet Pages
Description
You can create a completely different set of servlet pages for each HotSpot server you have, specifying the directory it will be stored in html-directory property of a HotSpot server profile (/ip hotspot profile). The default servlet pages are copied in the directory of your choice right after you create the profile. This directory can be accessed by connecting to the router with an FTP client. You can modify the pages as you like using the information from this section of the manual. Note that it is suggested to edit the files manually, as automated HTML editing tools may corrupt the pages by removing variables or other vital parts.
Available Servlet Pages
Main HTML servlet pages, which are shown to user:
• redirect.html – redirects user to another url (for example, to login page)
• login.html – login page shown to a user to ask for username and password. This page may take the following parameters:
o username – username
o password – either plain-text password (in case of PAP authentication) or MD5 hash of chap-id variable, password and CHAP challenge (in case of CHAP authentication). This value is used as e-mail address for trial users
o dst – original URL requested before the redirect. This will be opened on successfull login
o popup – whether to pop-up a status window on successfull login
o radius – send the attribute identified with in text string form to the RADIUS server (in case RADIUS authentication is used; lost otherwise)
o radiusu – send the attribute identified with in unsigned integer form to the RADIUS server (in case RADIUS authentication is used; lost otherwise)
o radius- – send the attribute identified with and vendor ID in text string form to the RADIUS server (in case RADIUS authentication is used; lost otherwise)
o radius-u – send the attribute identified with and vendor ID in unsigned integer form to the RADIUS server (in case RADIUS authentication is used; lost otherwise)
• md5.js – JavaScript for MD5 password hashing. Used together with http-chap login method
• alogin.html – page shown after client has logged in. It pops-up status page and redirects browser to originally requested page (before he/she was redirected to the HotSpot login page)
• status.html – status page, shows statistics for the client. It is also able to display advertisements automatically
• logout.html – logout page, shown after user is logged out. Shows final statistics about the finished session. This page may take the following additional parameters:
o erase-cookie – whether to erase cookies from the HotSpot server on logout (makes impossible to log in with cookie next time from the same browser, might be useful in multiuser environments)
• error.html – error page, shown on fatal errors only
Some other pages are available as well, if more control is needed:
• rlogin.html – page, which redirects client from some other URL to the login page, if authorization of the client is required to access that URL
• rstatus.html – similarly to rlogin.html, only in case if the client is already logged in and the original URL is not known
• radvert.html – redirects client to the scheduled advertisement link
• flogin.html – shown instead of login.html, if some error has happened (invalid username or password, for example)
• fstatus.html – shown instead of redirect, if status page is requested, but client is not logged in
• flogout.html – shown instead of redirect, if logout page is requested, but client is not logged in
Serving Servlet Pages
The HotSpot servlet recognizes 5 different request types:
1. request for a remote host
o if user is logged in and advertisement is due to be displayed, radvert.html is displayed. This page makes redirect to the scheduled advertisment page
o if user is logged in and advertisement is not scheduled for this user, the requested page is served
o if user is not logged in, but the destination host is allowed by walled garden, then the request is also served
o if user is not logged in, and the destination host is disallowed by walled garden, rlogin.html is displayed; if rlogin.html is not found, redirect.html is used to redirect to the login page
2. request for “/” on the HotSpot host
o if user is logged in, rstatus.html is displayed; if rstatus.html is not found, redirect.html is used to redirect to the status page
o if user is not logged in, rlogin.html is displayed; if rlogin.html is not found, redirect.html is used to redirect to the login page
3. request for “/login” page
o if user has successfully logged in (or is already logged in), alogin.html is displayed; if alogin.html is not found, redirect.html is used to redirect to the originally requested page or the status page (in case, original destination page was not given)
o if user is not logged in (username was not supplied, no error message appeared), login.html is showed
o if login procedure has failed (error message is supplied), flogin.html is displayed; if flogin.html is not found, login.html is used
o in case of fatal errors, error.html is showed
4. request for “/status” page
o if user is logged in, status.html is displayed
o if user is not logged in, fstatus.html is displayed; if fstatus.html is not found, redirect.html is used to redirect to the login page
5. request for ‘/logout’ page
o if user is logged in, logout.html is displayed
o if user is not logged in, flogout.html is displayed; if flogout.html is not found, redirect.html is used to redirect to the login page
Note that if it is not possible to meet a request using the pages stored on the router’s FTP server, Error 404 is displayed
There are many possibilities to customize what the HotSpot authentication pages look like:
• The pages are easily modifiable. They are stored on the router’s FTP server in the directory you choose for the respective HotSpot server profile.
• By changing the variables, which client sends to the HotSpot servlet, it is possible to reduce keyword count to one (username or password; for example, the client’s MAC address may be used as the other value) or even to zero (License Agreement; some predefined values general for all users or client’s MAC address may be used as username and password)
• Registration may occur on a different server (for example, on a server that is able to charge Credit Cards). Client’s MAC address may be passed to it, so that this information need not be written in manually. After the registration, the server should change RADIUS database enabling client to log in for some amount of time.
To insert variable in some place in HTML file, the $(var_name) syntax is used, where the “var_name” is the name of the variable (without quotes). This construction may be used in any HotSpot HTML file accessed as ‘/’, ‘/login’, ‘/status’ or ‘/logout’, as well as any text or HTML (.txt, .htm or .html) file stored on the HotSpot server (with the exception of traffic counters, which are available in status page only, and error, error-orig, chap-id, chap-challenge and popup variables, which are available in login page only). For example, to show a link to the login page, following construction can be used:
login
Variables
All of the Servlet HTML pages use variables to show user specific values. Variable names appear only in the HTML source of the servlet pages – they are automatically replaced with the respective values by the HotSpot Servlet. For most variables there is an example of their possible value included in brackets. All the described variables are valid in all servlet pages, but some of them just might be empty at the time they are accesses (for example, there is no uptime before a user has logged in).
• Common server variables:
o hostname – DNS name or IP address (if DNS name is not given) of the HotSpot Servlet (“hotspot.example.net”)
o identity – RouterOS identity name (“MikroTik”)
o login-by – authentication method used by user
o plain-passwd – a “yes/no” representation of whether HTTP-PAP login method is allowed (“no”)
o server-address – HotSpot server address (“10.5.50.1:80″)
o ssl-login – a “yes/no” representation of whether HTTPS method was used to access that servlet page (“no”)
o server-name – HotSpot server name (set in the /ip hotspot menu, as the name property)
• Links:
o link-login – link to login page including original URL requested (“http://10.5.50.1/login?dst=http://www.example.com/&#8221;)
o link-login-only – link to login page, not including original URL requested (“http://10.5.50.1/login&#8221;)
o link-logout – link to logout page (“http://10.5.50.1/logout&#8221;)
o link-status – link to status page (“http://10.5.50.1/status&#8221;)
o link-orig – original URL requested (“http://www.example.com/&#8221;)
• General client information
o domain – domain name of the user (“example.com”)
o interface-name – physical HotSpot interface name (in case of bridged interfaces, this will return the actual bridge port name)
o ip – IP address of the client (“10.5.50.2″)
o logged-in – “yes” if the user is logged in, otherwise – “no” (“yes”)
o mac – MAC address of the user (“01:23:45:67:89:AB”)
o trial – a “yes/no” representation of whether the user has access to trial time. If users trial time has expired, the value is “no”
o username – the name of the user (“John”)
• User status information:
o idle-timeout – idle timeout (“20m” or “” if none)
o idle-timeout-secs – idle timeout in seconds (“88″ or “0” if there is such timeout)
o limit-bytes-in – byte limit for send (“1000000″ or “—” if there is no limit)
o limit-bytes-out – byte limit for receive (“1000000″ or “—” if there is no limit)
o refresh-timeout – status page refresh timeout (“1m30s” or “” if none)
o refresh-timeout-secs – status page refresh timeout in seconds (“90s” or “0” if none)
o session-timeout – session time left for the user (“5h” or “” if none)
o session-timeout-secs – session time left for the user, in seconds (“3475″ or “0” if there is such timeout)
o session-time-left – session time left for the user (“5h” or “” if none)
o session-time-left-secs – session time left for the user, in seconds (“3475″ or “0” if there is such timeout)
o uptime – current session uptime (“10h2m33s”)
o uptime-secs – current session uptime in seconds (“125″)
• Traffic counters, which are available only in the status page:
o bytes-in – number of bytes received from the user (“15423″)
o bytes-in-nice – user-friendly form of number of bytes received from the user (“15423″)
o bytes-out – number of bytes sent to the user (“11352″)
o bytes-out-nice – user-friendly form of number of bytes sent to the user (“11352″)
o packets-in – number of packets received from the user (“251″)
o packets-out – number of packets sent to the user (“211″)
o remain-bytes-in – remaining bytes until limit-bytes-in will be reached (“337465″ or “—” if there is no limit)
o remain-bytes-out – remaining bytes until limit-bytes-out will be reached (“124455″ or “—” if there is no limit)
• Miscellaneous variables
o session-id – value of ‘session-id’ parameter in the last request
o var – value of ‘var’ parameter in the last request
o error – error message, if something failed (“invalid username or password”)
o error-orig – original error message (without translations retrieved from errors.txt), if something failed (“invalid username or password”)
o chap-id – value of chap ID (“\371″)
o chap-challenge – value of chap challenge (“\35715\3301321\234\145\245\303\253\142\246\133\175\375\316″)
o popup – whether to pop-up checkbox (“true” or “false”)
o advert-pending – whether an advertisement is pending to be displayed (“yes” or “no”)
• RADIUS-related variables
o radius – show the attribute identified with in text string form (in case RADIUS authentication was used; “” otherwise)
o radiusu – show the attribute identified with in unsigned integer form (in case RADIUS authentication was used; “0” otherwise)
o radius- – show the attribute identified with and vendor ID in text string form (in case RADIUS authentication was used; “” otherwise)
o radius-u – show the attribute identified with and vendor ID in unsigned integer form (in case RADIUS authentication was used; “0” otherwise)
Working with variables
$(if ) statements can be used in theses pages. Following content will be included, if value of will not be an empty string. It is an equivalent to $(if != “”) It is possible to compare on equivalence as well: $(if == ) These statements have effect until $(elif ), $(else) or $(endif). In general case it looks like this:
some content, which will always be displayed
$(if username == john)
Hey, your username is john
$(elif username == dizzy)
Hello, Dizzy! How are you? Your administrator.
$(elif ip == 10.1.2.3)
You are sitting at that crappy computer, which is damn slow…
$(elif mac == 00:01:02:03:04:05)
This is an ethernet card, which was stolen few months ago…
$(else)
I don’t know who you are, so lets live in peace.
$(endif)
other content, which will always be displayed

Only one of those expressions will be shown. Which one – depends on values of those variables for each client.
Customizing Error Messages
All error messages are stored in the errors.txt file within the respective HotSpot servlet directory. You can change and translate all these messages to your native language. To do so, edit the errors.txt file. You can also use variables in the messages. All instructions are given in that file.
Multiple Versions of HotSpot Pages
Multiple HotSpot page sets for the same HotSpot server are supported. They can be chosen by user (to select language) or automatically by JavaScript (to select PDA/regular version of HTML pages).
To utilize this feature, create subdirectories in HotSpot HTML directory, and place those HTML files, which are different, in that subdirectory. For example, to translate everything in Latvian, subdirectory “lv” can be created with login.html, logout.html, status.html, alogin.html, radvert.html and errors.txt files, which are translated into Latvian. If the requested HTML page can not be found in the requested subdirectory, the corresponding HTML file from the main directory will be used. Then main login.html file would contain link to “/lv/login?dst=$(link-orig-esc)”, which then displays Latvian version of login page: Latviski . And Latvian version would contain link to English version: English
Another way of referencing directories is to specify ‘target’ variable:
Latviski
English

After preferred directory has been selected (for example, “lv”), all links to local HotSpot pages will contain that path (for example, $(link-status) = “http://hotspot.mt.lv/lv/status&#8221;). So, if all HotSpot pages reference links using “$(link-xxx)” variables, then no more changes are to be made – each client will stay within the selected directory all the time.
Notes
If you want to use HTTP-CHAP authentication method it is supposed that you include the doLogin() function (which references to the md5.js which must be already loaded) before the Submit action of the login form. Otherwise, CHAP login will fail.
The resulting password to be sent to the HotSpot gateway in case of HTTP-CHAP method, is formed MD5-hashing the concatenation of the following: chap-id, the password of the user and chap-challenge (in the given order)
In case variables are to be used in link directly, then they must be escaped accordingly. For example, in login page, link will not work as intended, if username will be “123&456=1 2″. In this case instead of $(user), its escaped version must be used: $(user-esc): link. Now the same username will be converted to “123%26456%3D1+2″, which is the valid representation of “123&456=1 2″ in URL. This trick may be used with any variables, not only with $(username).
There is a boolean parameter “erase-cookie” to the logout page, which may be either “on” or “true” to delete user cookie on logout (so that the user would not be automatically logged on when he/she opens a browser next time.
Example
With basic HTML language knowledge and the examples below it should be easy to implement the ideas described above.
• To provide predefined value as username, in login.html change:

to this line:

(where hsuser is the username you are providing)
• To provide predefined value as password, in login.html change:

to this line:

(where hspass is the password you are providing)
• To send client’s MAC address to a registration server in form of:

https://www.example.com/register.html?mac=XX:XX:XX:XX:XX:XX

change the Login button link in login.html to:

https://www.example.com/register.html?mac=$(mac)

(you should correct the link to point to your server)
• To show a banner after user login, in alogin.html after
$(if popup == ‘true’)
add the following line:
open(‘http://www.example.com/your-banner-page.html&#8217;, ‘my-banner-name’,”);
(you should correct the link to point to the page you want to show)
• To choose different page shown after login, in login.html change:

to this line:

(you should correct the link to point to your server)
• To erase the cookie on logoff, in the page containing link to the logout (for example, in status.html) change:
open(‘$(link-logout)’, ‘hotspot_logout’, …
to this:
open(‘$(link-logout)?erase-cookie=on’, ‘hotspot_logout’, …
or alternatively add this line:

before this one:

An another example is making HotSpot to authenticate on a remote server (which may, for example, perform creditcard charging):
• Allow direct access to the external server in walled-garden (either HTTP-based, or IP-based)
• Modify login page of the HotSpot servlet to redirect to the external authentication server. The external server should modify RADIUS database as needed
Here is an example of such a login page to put on the HotSpot router (it is redirecting to https://auth.example.com/login.php, replace with the actual address of an external authentication server):

• The external server can log in a HotSpot client by redirecting it back to the original HotSpot servlet login page, specifying the correct username and password
Here is an example of such a page (it is redirecting to https://hotspot.example.com/login, replace with the actual address of a HotSpot router; also, it is displaying http://www.mikrotik.com after successful login, replace with what needed):

Hotspot login page

• Hotspot will ask RADIUS server whether to allow the login or not. If not allowed, alogin.html page will be displayed (it can be modified to do anything). If not allowed, flogin.html (or login.html) page will be displayed, which will redirect client back to the external authentication server.
• Note: as shown in these examples, HTTPS protocol and POST method can be used to secure communications.
Possible Error Messages
Description
There are two kinds of errors: fatal and non-fatal. Fatal errors are shown on a separate HTML page called error.html. Non-fatal errors are basically indicating incorrect user actions and are shown on the login form.
General non-fatal errors:
• You are not logged in – trying to access the status page or log off while not logged in. Solution: log in
• already authorizing, retry later – authorization in progress. Client already has issued an authorization request which is not yet complete. Solution: wait for the current request to be completed, and then try again
• chap-missing = web browser did not send challenge response (try again, enable JavaScript) – trying to log in with HTTP-CHAP method using MD5 hash, but HotSpot server does not know the challenge used for the hash. This may happen if you use BACK buttons in browser; if JavaScript is not enabled in web browser; if login.html page is not valid; or if challenge value has expired on server (more than 1h of inactivity). Solution: instructing browser to reload (refresh) the login page usually helps if JavaScript is enabled and login.html page is valid
• invalid username ($(username)): this MAC address is not yours – trying to log in using a MAC address username different from the actual user’s MAC address. Solution: no – users with usernames that look like a MAC address (eg., 12:34:56:78:9a:bc) may only log in from the MAC address specified as their user name
• session limit reached ($(error-orig)) – depending on licence number of active HotSpot clients is limited to some number. The error is displayed when this limit is reached. Solution: try to log in later when there will be less concurrent user sessions, or buy an another license that allows more simultaneous sessions
• hotspot service is shutting down – RouterOS is currently being restarted or shut down. Solution: wait until the service will be available again
General fatal errors:
• internal error ($(error-orig)) – this should never happen. If it will, error page will be shown displaying this error message (error-orig will describe what has happened). Solution: correct the error reported
• configuration error ($(error-orig)) – the HotSpot server is not configured properly (error-orig will describe what has happened). Solution: correct the error reported
• cannot assign ip address – no more free addresses from pool – unable to get an IP address from an IP pool as there is no more free IP addresses in that pool. Solution: make sure there is a sufficient amount of free IP addresses in IP pool
Local HotSpot user database non-fatal errors:
• invalid username or password – self-explanatory
• user $(username) is not allowed to log in from this MAC address – trying to log in from a MAC address different from specified in user database. Solution: log in from the correct MAC address or take out the limitation
• user $(username) has reached uptime limit – self-explanatory
• user $(username) has reached traffic limit – either limit-bytes-in or limit-bytes-out limit is reached
• no more sessions are allowed for user $(username) – the shared-users limit for the user’s profile is reached. Solution: wait until someone with this username logs out, use different login name or extend the shared-users limit
RADIUS client non-fatal errors:
• invalid username or password – RADIUS server has rejected the username and password sent to it without specifying a reason. Cause: either wrong username and/or password, or other error. Solution: should be clarified in RADIUS server’s log files
• – this may be any message (any text string) sent back by RADIUS server. Consult with your RADIUS server’s documentation for further information
RADIUS client fatal errors:
• RADIUS server is not responding – user is being authenticated by RADIUS server, but no response is received from it. Solution: check whether the RADIUS server is running and is reachable from the HotSpot router
HotSpot How-to’s
Description
This section will focus on some simple examples of how to use your HotSpot system, as well as give some useful ideas.
Setting up HTTPS authorization
At first certificate must be present with decrypted private key:
[admin@MikroTik] > /certificate print
Flags: K – decrypted-private-key, Q – private-key, R – rsa, D – dsa
0 KR name=”hotspot.example.net”
subject=C=LV,L=Riga,O=MT,OU=dev,CN=hotspot.example.net,
emailAddress=admin@hotsot.example.net
issuer=C=LV,L=Riga,O=MT,OU=dev,CN=hotsot.example.net,
emailAddress=admin@hotsot.example.net
serial-number=”0″ email=admin@hotsot.example.net
invalid-before=oct/27/2004 11:43:22 invalid-after=oct/27/2005 11:43:22
ca=yes

Then we can use that certificate for HotSpot:
/ip hotspot profile set default login-by=cookie,http-chap,https \
ssl-certificate=hotsot.example.net

After that we can see, that HTTPS is running on HotSpot interface:
[admin@MikroTik] > /ip hotspot print
Flags: X – disabled, I – invalid, S – HTTPS
# NAME INTERFACE ADDRESS-POOL PROFILE IDLE-TIMEOUT
0 S hs-local local default 00:05:00

Bypass HotSpot for some devices in HotSpot network
All IP binding entries with type property set to bypassed, will not be asked to authorize – it means that they will have login-free access:
[admin@MikroTik] ip hotspot ip-binding> print
Flags: X – disabled, P – bypassed, B – blocked
# MAC-ADDRESS ADDRESS TO-ADDRESS SERVER
0 P 10.11.12.3

If all fields has been filled in the ip-binding table and type has been set to bypassed, then the IP address of this entry will be accessible from public interfaces immediately:
[admin@MikroTik] ip hotspot ip-binding> print
Flags: X – disabled, P – bypassed, B – blocked
# MAC-ADDRESS ADDRESS TO-ADDRESS SERVER
0 P 10.11.12.3
1 P 00:01:02:03:04:05 10.11.12.3 10.11.12.3 hs-local
[admin@MikroTik] ip hotspot ip-binding> .. host print
Flags: S – static, H – DHCP, D – dynamic, A – authorized, P – bypassed
# MAC-ADDRESS ADDRESS TO-ADDRESS SERVER IDLE-TIMEOUT
0 P 00:01:02:03:04:05 10.11.12.3 10.11.12.3 hs-local

© Copyright 1999-2007, MikroTik. All rights reserved. Mikrotik, RouterOS and RouterBOARD are trademarks of Mikrotikls SIA. Other trademarks and registered trademarks mentioned herein are properties of their respective owners.

Home >
Documentation >
V3.0 >
Web Proxy
PDF version

Web Proxy
Document revision: 1.5 (December 12, 2007, 11:44 GMT)
Applies to: V3.0
General Information
Summary
The MikroTik RouterOS implements the following proxy server features:
• Regular HTTP proxy
• Transparent proxy. Can be transparent and regular at the same time
• Access list by source, destination, URL and requested method
• Cache access list (specifies which objects to cache, and which not)
• Direct Access List (specifies which resources should be accessed directly, and which – through another proxy server)
• Logging facility
Quick Setup Guide
To set up a 1 GiB large web cache, which will listen on port 8000, do the following:
[admin@MikroTik] ip proxy> set enabled=yes port=8000 max-cache-size=1048576
[admin@MikroTik] ip proxy> print
enabled: yes
src-address: 0.0.0.0
port: 8000
parent-proxy: 0.0.0.0
parent-proxy-port: 0
cache-drive: system
cache-administrator: “webmaster”
max-cache-size: 1048576KiB
cache-on-disk: no
max-client-connections: 600
max-server-connections: 600
max-fresh-time: 3d
serialize-connections: no
always-from-cache: no
cache-hit-dscp: 4
[admin@MikroTik] ip proxy>
Remember to secure your proxy by preventing unauthorized access to it, otherwise it may be used as an open proxy. Also you need to setup destination NAT in order to utilize transparent proxying facility:
[admin@MikroTik] ip firewall nat> add chain=dstnat protocol=tcp dst-port=80 action=redirect to-ports=8000
[admin@MikroTik] ip firewall nat>
Specifications
Packages required: web-proxy
License required: Level3
Submenu level: /ip web-proxy
Standards and Technologies: HTTP/1.0, HTTP/1.1, FTP
Hardware usage: uses memory and disk space, if available (see description below)
Description
Web proxy performs Internet object cache function by storing requested Internet objects, i.e., data available via HTTP and FTP protocols on a system positioned closer to the recipient than the site the data is originated from. Here ‘closer’ means increased path reliability, speed or both. Web browsers can then use the local proxy cache to speed up access and external reduce bandwidth consumption.
When setting up Web proxy, make sure it serves only your clients, and is not misused as relay. Please read the security notice in the Access List Section!
Note that it may be useful to have Web proxy running even with no cache when you want to use it as something like HTTP and FTP firewall (for example, denying access to mp3 files) or to redirect requests to external proxy with large cache drives transparently.
Setup
Submenu level: /ip proxy
Property Description
always-from-cache (yes | no; default: no) – ignore client refresh requests if the content is considered fresh
cache-administrator (text; default: webmaster) – administrator’s e-mail displayed on proxy error page
cache-drive (system | name; default: system) – specifies the target disk drive to be used for storing cached objects. You can use console completion to see the list of available drives
cache-hit-dscp (integer: 0..63) – automatically mark cache hit with the provided DSCP value
cache-on-disk (yes | no; default: no) – whether to store cache files on disk or in RAM filesystem
enabled (yes | no; default: no) – specifies whether the web proxy is enabled
max-cache-size (none | unlimited | integer: 0..4294967295; default: none) – specifies the maximal disk cache size, measured in kibibytes
max-client-connections (integer; default: 600) – maximum number of concurrent client connections accepted by the proxy. All further connections will be rejected
max-fresh-time (time; default: 3d) – an upper limit on how long objects without an explicit expiry time will be considered fresh
max-server-connections (integer; default: 600) – maximum number of concurrent proxy connections to external servers. All further connections will be put on hold until some of the existing server connections will terminate
parent-proxy (IP address:port; default: 0.0.0.0) – IP address of the upper-level (parent) proxy
parent-proxy-port (port) – TCP port the parent proxy is active on
port (port{1,10}; default: 3128) – specifies the port(s) the web proxy will be listening on
serialize-connections (yes | no; default: no) – Do not make multiple connections to server for multiple client connections, if possible (i.e. server supports persistent HTTP connections). Clients will be served on FIFO principle; next client is processed when response transfer to the previous one is completed. If a client is idle for too long (max 5 seconds by default), it will give up waiting and open another connection to the server
src-address (IP address; default: 0.0.0.0) – the web-proxy will use this address connecting to the parent proxy or web site.
0.0.0.0 – appropriate src-address will be automatically taken from the routing table (preferred source of the respective route)
Notes
The web proxy listens to all IP addresses that the router has in its IP address list.
Example
To enable proxy on port 8080 with maximal available cache size:
[admin@MikroTik] ip proxy> set enabled=yes port=8080 \
\… max-cache-size=unlimited
[admin@MikroTik] ip proxy> print
enabled: yes
src-address: 0.0.0.0
port: 8000
parent-proxy: 0.0.0.0
parent-proxy-port: 0
cache-drive: system
cache-administrator: “webmaster”
max-cache-size: 21000KiB
cache-on-disk: no
max-client-connections: 600
max-server-connections: 600
max-fresh-time: 3d
serialize-connections: no
always-from-cache: no
cache-hit-dscp: 4
[admin@MikroTik] ip proxy>
Note how the max-cache-size value has been calculated from the unlimited to an accurate value in kibibytes
Proxy Monitoring
Command name: /ip proxy monitor
Property Description
cache-used (read-only: integer) – the amount of disk (or RAM if the cache is stored only in RAM) used by the cache
free-disk-space (read-only: integer) – the amount of free space on the cache drive
hits (read-only: integer) – number of client requests resolved from the cache
hits-sent-to-clients (read-only: integer) – the amount of cache hits sent to client
received-from-servers (read-only: integer) – total amount of data received from the external servers
requests (read-only: integer) – total number of client requests to the proxy
sent-to-clients (read-only: integer) – total amount of data sent to the clients
status (read-only: text; default: stopped) – display status information of the proxy server
stopped – proxy is disabled and is not running
running – proxy is enabled and running
formatting-disk – the cache drive is being formatted
checking-disk – the cache drive is being checked for errors and cache inconsistencies
invalid-address – proxy is enabled, but not running because of invalid address (you should change address or port)
total-disk-size (read-only: integer) – size of the cache drive
total-ram-used (read-only: integer) – the amount of memory used by the proxy (excluding RAM cache size)
uptime (read-only: time) – the time since the proxy has been started last time
Access List
Submenu level: /ip proxy access
Description
Access list is configured in the same way as MikroTik RouterOS firewall rules. Rules are processed from the top to the bottom. First matching rule specifies decision of what to do with this connection. There is a total of 6 classifiers that specify matching constraints. If none of these classifiers is specified, the particular rule will match any connection.
If connection is matched by a rule, action property of this rule specifies whether connection will be allowed or not. If some connection does not match any rule, it will be allowed.
Property Description
action (allow | deny; default: allow) – specifies whether to pass or deny matched packets
dst-address (IP address/netmask) – destination address of the IP packet
dst-host (wildcard) – IP address or DNS name used to make connection the target server (this is the string user wrote in his/her browser before specifying port and path to a particular web page)
dst-port (port{1,10}) – a list or range of ports the packet is destined to
hits (read-only: integer) – the number of requests that were policed by this rule
local-port (port) – specifies the port of the web proxy via which the packet was received. This value should match one of the ports web proxy is listening on.
method (any | connect | delete | get | head | options | post | put | trace) – HTTP method used in the request (see HTTP Methods section at the end of this document)
path (wildcard) – name of the requested page within the target server (i.e. the name of a particular web page or document without the name of the server it resides on)
redirect-to (text) – in case access is denied by this rule, the user shall be redirected to the URL specified here
src-address (IP address/netmask) – source address of the IP packet
Notes
It is strongly recommended to deny all IP addresses except those behind the router as the proxy still may be used to access your internal-use-only (intranet) web servers. Also, consult examples in Firewall Manual on how to protect your router.
Wildcard property url matches a complete string (i.e., they will not match “example.com” if they are set to “example”). Available wildcards are ‘*’ (match any number of any characters) and ‘?’ (match any one character). Regular expressions are also accepted here, but if the property should be treated as a regular expression, it should start with a colon (‘:’).
Small hits in using regular expressions:
• \\ symbol sequence is used to enter \ character in console
• \. pattern means . only (in regular expressions single dot in pattern means any symbol)
• to show that no symbols are allowed before the given pattern, we use ^ symbol at the beginning of the pattern
• to specify that no symbols are allowed after the given pattern, we use $ symbol at the end of the pattern
• to enter [ or ] symbols, you should escape them with backslash \.
Direct Access List
Submenu level: /ip proxy direct
Description
If parent-proxy property is specified, it is possible to tell the proxy server whether to try to pass the request to the parent proxy or to resolve it connecting to the requested server directly. Direct Access List is managed just like Proxy Access List described in the previous chapter except the action argument.
Property Description
action (allow | deny; default: allow) – specifies the action to perform on matched packets
allow – always resolve matched requests directly bypassing the parent router
deny – resolve matched requests through the parent proxy. If no one is specified this has the same effect as allow
dst-address (IP address/netmask) – destination address of the IP packet
dst-host (wildcard) – IP address or DNS name used to make connection the target server (this is the string user wrote in his/her browser before specifying port and path to a particular web page)
dst-port (port{1,10}) – a list or range of ports the packet is destined to
local-port (port) – specifies the port of the web proxy via which the packet was received. This value should match one of the ports web proxy is listening on.
method (any | connect | delete | get | head | options | post | put | trace) – HTTP method used in the request (see HTTP Methods section in the end of this document)
path (wildcard) – name of the requested page within the target server (i.e. the name of a particular web page or document without the name of the server it resides on)
src-address (IP address/netmask) – source address of the IP packet
Notes
Unlike the access list, the direct proxy access list has default action equal to deny. It takes place when no rules are specified or a particular request did not match any rule.
Cache Management
Submenu level: /ip proxy cache
Description
Cache access list specifies, which requests (domains, servers, pages) have to be cached locally by web proxy, and which not. This list is implemented exactly the same way as web proxy access list. Default action is to cache object (if no matching rule is found).
Property Description
action (allow | deny; default: allow) – specifies the action to perform on matched packets
allow – cache objects from matched request
deny – do not cache objects from matched request
dst-address (IP address/netmask) – destination address of the IP packet
dst-port (port{1,10}) – a list or range of ports the packet is destined to
local-port (port) – specifies the port of the web proxy via which the packet was received. This value should match one of the ports web proxy is listening on.
method (any | connect | delete | get | head | options | post | put | trace) – HTTP method used in the request (see HTTP Methods section in the end of this document)
path (wildcard) – name of the requested page within the target server (i.e. the name of a particular web page or document without the name of the server it resides on)
path (wildcard) – name of the requested page within the target server (i.e. the name of a particular web page or document without the name of the server it resides on)
src-address (IP address/netmask) – source address of the IP packet
Connection List
Submenu level: /ip proxy connections
Description
This menu contains the list of current connections the proxy is serving
Property Description
dst-address (read-only: IP address) – IP address of to which data are passed via this proxy
protocol (read-only: text) – protocol name
rx-bytes (read-only: integer) – the amount of bytes received from the remote end
src-address (read-only: IP address) – IP address of the remote end of the connection
state (read-only: connecting | idle | resolving | rx-body | rx-header | tx-body | tx-header | ) – opened connection state
connecting – establishing connection with server
idle – waiting for next client to serve
resolving – resolving server’s DNS name
rx-body – receiving HTTP body
rx-header – receiving HTTP header; or waiting for next request from client
tx-body – transmitting HTTP body
tx-header – transmitting HTTP header
tx-bytes (read-only: integer) – the amount of bytes sent to the remote end
Cache Contents
Submenu level: /ip proxy cache-contents
Description
This menu lists all the files stored in the cache
Property Description
file-size (read-only: integer) – size of the stored file
last-accessed (read-only: date) – date of the last access to the resource
last-accessed-time (read-only: time) – time of the last access to the resource
last-modified (read-only: date) – modification date
last-modified-time (read-only: time) – modification time
uri (read-only: text) – full resource name
Cache inserts
Submenu level: /ip proxy inserts
Description
This menu shows statistics on objects stored in cache (cache inserts)
Property Description
denied (read-only: integer) – number of inserts denied by the caching list
errors (read-only: integer) – number of disk or other system-related errors
no-memory (read-only: integer) – number of objects not stored because there was not enough memory
successes (read-only: integer) – number of successfull cache inserts
too-large (read-only: integer) – number of objects too large to store
Cache Lookups
Submenu level: /ip proxy lookups
Description
This menu shows statistics on objects read from cache (cache lookups)
Property Description
denied (read-only: integer) – number of requests denied by the access list
expired (read-only: integer) – number of requests found in cache, but expired, and, thus, requested from an external server
no-expiration-info (read-only: integer) – conditional request received for a page that does not have the information to compare the request with
non-cacheable (read-only: integer) – number of requests requested from the external servers unconditionally (as their caching is denied by the cache access list)
not-found (read-only: integer) – number of requests not found in the cache, and, thus, requested from an external server (or parent proxy if configured accordingly)
successes (read-only: integer) – number of requests found in the cache
Complementary Tools
Description
Web proxy has additional commands to handle non-system drive used for caching purposes and to recover the proxy from severe file system errors.
Command Description
check-drive – checks non-system cache drive for errors
clear-cache – deletes existing cache and creates new cache directories
format-drive – formats non-system cache drive and prepairs it for holding the cache
Transparent Mode
Description
Transparent proxy feature performs request caching invisibly to the end-user. This way the user does not notice that his connection is being processed by the proxy and therefore does not need to perform any additional configuration of the software he is using.
This feature may as well be combined with bridge to simplify deployment of web proxy in the existing infrastructure.
To enable the transparent mode, place a firewall rule in destination NAT, specifying which connections, id est traffic coming to which ports should be redirected to the proxy.
Notes
Only HTTP traffic is supported in transparent mode of the web proxy. HTTPS and FTP protocols are not going to work this way.
Example
To configure the router to transparently redirect all connections coming from ether1 interface to port 80 to the web proxy listening on port 8080, then add the following destination NAT rule:
[admin@MikroTik] > /ip firewall nat add in-interface=ether1 dst-port=80 \
\… protocol=tcp action=redirect to-ports=8080 chain=dstnat
[admin@MikroTik] > /ip firewall nat print
Flags: X – disabled, I – invalid, D – dynamic
0 chain=dstnat protocol=tcp in-interface=ether1 dst-port=80 action=redirect
to-ports=8080
[admin@MikroTik] >
Notes
Be aware, that you will not be able to access the router’s web page after addition of the rule above unless you will change the port for the www service under /ip service submenu to a different value or explicitly exclude router’s IP address from those to be matched, like:
/ip firewall nat add in-interface=ether1 dst-port=80 \
\… protocol=tcp action=redirect to-ports=8080 chain=dstnat dst-address=!1.1.1.1/32
It is assumed that the router’s address is 1.1.1.1/32.
HTTP Methods
Description
OPTIONS
This method is a request of information about the communication options available on the chain between the client and the server identified by the Request-URI. The method allows the client to determine the options and (or) the requirements associated with a resource without initiating any resource retrieval
GET
This method retrieves whatever information identified by the Request-URI. If the Request-URI refers to a data processing process than the response to the GET method should contain data produced by the process, not the source code of the process procedure(-s), unless the source is the result of the process.
The GET method can become a conditional GET if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. The conditional GET method is used to reduce the network traffic specifying that the transfer of the entity should occur only under circumstances described by conditional header field(-s).
The GET method can become a partial GET if the request message includes a Range header field. The partial GET method intends to reduce unnecessary network usage by requesting only parts of entities without transferring data already held by client.
The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching.
HEAD
This method shares all features of GET method except that the server must not return a message-body in the response. This retrieves the metainformation of the entity implied by the request which leads to a wide usage of it for testing hypertext links for validity, accessibility, and recent modification.
The response to a HEAD request may be cacheable in the way that the information contained in the response may be used to update previously cached entity identified by that Request-URI.
POST
This method requests that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI.
The actual action performed by the POST method is determined by the origin server and usually is Request-URI dependent.
Responses to POST method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.
PUT
This method requests that the enclosed entity be stored under the supplied Request-URI. If another entity exists under specified Request-URI, the enclosed entity should be considered as updated (newer) version of that residing on the origin server. If the Request-URI is not pointing to an existing resource, the origin server should create a resource with that URI.
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries should be treated as stale. Responses to this method are not cacheable.
TRACE
This method invokes a remote, application-layer loop-back of the request message. The final recipient of the request should reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of 0 in the request. A TRACE request must not include an entity.
Responses to this method MUST NOT be cached.
© Copyright 1999-2007, MikroTik. All rights reserved. Mikrotik, RouterOS and RouterBOARD are trademarks of Mikrotikls SIA. Other trademarks and registered trademarks mentioned herein are properties of their respective owners.
Home >
Documentation >
V3.0 >
Web Proxy
PDF version

Web Proxy
Document revision: 1.5 (December 12, 2007, 11:44 GMT)
Applies to: V3.0
General Information
Summary
The MikroTik RouterOS implements the following proxy server features:
• Regular HTTP proxy
• Transparent proxy. Can be transparent and regular at the same time
• Access list by source, destination, URL and requested method
• Cache access list (specifies which objects to cache, and which not)
• Direct Access List (specifies which resources should be accessed directly, and which – through another proxy server)
• Logging facility
Quick Setup Guide
To set up a 1 GiB large web cache, which will listen on port 8000, do the following:
[admin@MikroTik] ip proxy> set enabled=yes port=8000 max-cache-size=1048576
[admin@MikroTik] ip proxy> print
enabled: yes
src-address: 0.0.0.0
port: 8000
parent-proxy: 0.0.0.0
parent-proxy-port: 0
cache-drive: system
cache-administrator: “webmaster”
max-cache-size: 1048576KiB
cache-on-disk: no
max-client-connections: 600
max-server-connections: 600
max-fresh-time: 3d
serialize-connections: no
always-from-cache: no
cache-hit-dscp: 4
[admin@MikroTik] ip proxy>
Remember to secure your proxy by preventing unauthorized access to it, otherwise it may be used as an open proxy. Also you need to setup destination NAT in order to utilize transparent proxying facility:
[admin@MikroTik] ip firewall nat> add chain=dstnat protocol=tcp dst-port=80 action=redirect to-ports=8000
[admin@MikroTik] ip firewall nat>
Specifications
Packages required: web-proxy
License required: Level3
Submenu level: /ip web-proxy
Standards and Technologies: HTTP/1.0, HTTP/1.1, FTP
Hardware usage: uses memory and disk space, if available (see description below)
Description
Web proxy performs Internet object cache function by storing requested Internet objects, i.e., data available via HTTP and FTP protocols on a system positioned closer to the recipient than the site the data is originated from. Here ‘closer’ means increased path reliability, speed or both. Web browsers can then use the local proxy cache to speed up access and external reduce bandwidth consumption.
When setting up Web proxy, make sure it serves only your clients, and is not misused as relay. Please read the security notice in the Access List Section!
Note that it may be useful to have Web proxy running even with no cache when you want to use it as something like HTTP and FTP firewall (for example, denying access to mp3 files) or to redirect requests to external proxy with large cache drives transparently.
Setup
Submenu level: /ip proxy
Property Description
always-from-cache (yes | no; default: no) – ignore client refresh requests if the content is considered fresh
cache-administrator (text; default: webmaster) – administrator’s e-mail displayed on proxy error page
cache-drive (system | name; default: system) – specifies the target disk drive to be used for storing cached objects. You can use console completion to see the list of available drives
cache-hit-dscp (integer: 0..63) – automatically mark cache hit with the provided DSCP value
cache-on-disk (yes | no; default: no) – whether to store cache files on disk or in RAM filesystem
enabled (yes | no; default: no) – specifies whether the web proxy is enabled
max-cache-size (none | unlimited | integer: 0..4294967295; default: none) – specifies the maximal disk cache size, measured in kibibytes
max-client-connections (integer; default: 600) – maximum number of concurrent client connections accepted by the proxy. All further connections will be rejected
max-fresh-time (time; default: 3d) – an upper limit on how long objects without an explicit expiry time will be considered fresh
max-server-connections (integer; default: 600) – maximum number of concurrent proxy connections to external servers. All further connections will be put on hold until some of the existing server connections will terminate
parent-proxy (IP address:port; default: 0.0.0.0) – IP address of the upper-level (parent) proxy
parent-proxy-port (port) – TCP port the parent proxy is active on
port (port{1,10}; default: 3128) – specifies the port(s) the web proxy will be listening on
serialize-connections (yes | no; default: no) – Do not make multiple connections to server for multiple client connections, if possible (i.e. server supports persistent HTTP connections). Clients will be served on FIFO principle; next client is processed when response transfer to the previous one is completed. If a client is idle for too long (max 5 seconds by default), it will give up waiting and open another connection to the server
src-address (IP address; default: 0.0.0.0) – the web-proxy will use this address connecting to the parent proxy or web site.
0.0.0.0 – appropriate src-address will be automatically taken from the routing table (preferred source of the respective route)
Notes
The web proxy listens to all IP addresses that the router has in its IP address list.
Example
To enable proxy on port 8080 with maximal available cache size:
[admin@MikroTik] ip proxy> set enabled=yes port=8080 \
\… max-cache-size=unlimited
[admin@MikroTik] ip proxy> print
enabled: yes
src-address: 0.0.0.0
port: 8000
parent-proxy: 0.0.0.0
parent-proxy-port: 0
cache-drive: system
cache-administrator: “webmaster”
max-cache-size: 21000KiB
cache-on-disk: no
max-client-connections: 600
max-server-connections: 600
max-fresh-time: 3d
serialize-connections: no
always-from-cache: no
cache-hit-dscp: 4
[admin@MikroTik] ip proxy>
Note how the max-cache-size value has been calculated from the unlimited to an accurate value in kibibytes
Proxy Monitoring
Command name: /ip proxy monitor
Property Description
cache-used (read-only: integer) – the amount of disk (or RAM if the cache is stored only in RAM) used by the cache
free-disk-space (read-only: integer) – the amount of free space on the cache drive
hits (read-only: integer) – number of client requests resolved from the cache
hits-sent-to-clients (read-only: integer) – the amount of cache hits sent to client
received-from-servers (read-only: integer) – total amount of data received from the external servers
requests (read-only: integer) – total number of client requests to the proxy
sent-to-clients (read-only: integer) – total amount of data sent to the clients
status (read-only: text; default: stopped) – display status information of the proxy server
stopped – proxy is disabled and is not running
running – proxy is enabled and running
formatting-disk – the cache drive is being formatted
checking-disk – the cache drive is being checked for errors and cache inconsistencies
invalid-address – proxy is enabled, but not running because of invalid address (you should change address or port)
total-disk-size (read-only: integer) – size of the cache drive
total-ram-used (read-only: integer) – the amount of memory used by the proxy (excluding RAM cache size)
uptime (read-only: time) – the time since the proxy has been started last time
Access List
Submenu level: /ip proxy access
Description
Access list is configured in the same way as MikroTik RouterOS firewall rules. Rules are processed from the top to the bottom. First matching rule specifies decision of what to do with this connection. There is a total of 6 classifiers that specify matching constraints. If none of these classifiers is specified, the particular rule will match any connection.
If connection is matched by a rule, action property of this rule specifies whether connection will be allowed or not. If some connection does not match any rule, it will be allowed.
Property Description
action (allow | deny; default: allow) – specifies whether to pass or deny matched packets
dst-address (IP address/netmask) – destination address of the IP packet
dst-host (wildcard) – IP address or DNS name used to make connection the target server (this is the string user wrote in his/her browser before specifying port and path to a particular web page)
dst-port (port{1,10}) – a list or range of ports the packet is destined to
hits (read-only: integer) – the number of requests that were policed by this rule
local-port (port) – specifies the port of the web proxy via which the packet was received. This value should match one of the ports web proxy is listening on.
method (any | connect | delete | get | head | options | post | put | trace) – HTTP method used in the request (see HTTP Methods section at the end of this document)
path (wildcard) – name of the requested page within the target server (i.e. the name of a particular web page or document without the name of the server it resides on)
redirect-to (text) – in case access is denied by this rule, the user shall be redirected to the URL specified here
src-address (IP address/netmask) – source address of the IP packet
Notes
It is strongly recommended to deny all IP addresses except those behind the router as the proxy still may be used to access your internal-use-only (intranet) web servers. Also, consult examples in Firewall Manual on how to protect your router.
Wildcard property url matches a complete string (i.e., they will not match “example.com” if they are set to “example”). Available wildcards are ‘*’ (match any number of any characters) and ‘?’ (match any one character). Regular expressions are also accepted here, but if the property should be treated as a regular expression, it should start with a colon (‘:’).
Small hits in using regular expressions:
• \\ symbol sequence is used to enter \ character in console
• \. pattern means . only (in regular expressions single dot in pattern means any symbol)
• to show that no symbols are allowed before the given pattern, we use ^ symbol at the beginning of the pattern
• to specify that no symbols are allowed after the given pattern, we use $ symbol at the end of the pattern
• to enter [ or ] symbols, you should escape them with backslash \.
Direct Access List
Submenu level: /ip proxy direct
Description
If parent-proxy property is specified, it is possible to tell the proxy server whether to try to pass the request to the parent proxy or to resolve it connecting to the requested server directly. Direct Access List is managed just like Proxy Access List described in the previous chapter except the action argument.
Property Description
action (allow | deny; default: allow) – specifies the action to perform on matched packets
allow – always resolve matched requests directly bypassing the parent router
deny – resolve matched requests through the parent proxy. If no one is specified this has the same effect as allow
dst-address (IP address/netmask) – destination address of the IP packet
dst-host (wildcard) – IP address or DNS name used to make connection the target server (this is the string user wrote in his/her browser before specifying port and path to a particular web page)
dst-port (port{1,10}) – a list or range of ports the packet is destined to
local-port (port) – specifies the port of the web proxy via which the packet was received. This value should match one of the ports web proxy is listening on.
method (any | connect | delete | get | head | options | post | put | trace) – HTTP method used in the request (see HTTP Methods section in the end of this document)
path (wildcard) – name of the requested page within the target server (i.e. the name of a particular web page or document without the name of the server it resides on)
src-address (IP address/netmask) – source address of the IP packet
Notes
Unlike the access list, the direct proxy access list has default action equal to deny. It takes place when no rules are specified or a particular request did not match any rule.
Cache Management
Submenu level: /ip proxy cache
Description
Cache access list specifies, which requests (domains, servers, pages) have to be cached locally by web proxy, and which not. This list is implemented exactly the same way as web proxy access list. Default action is to cache object (if no matching rule is found).
Property Description
action (allow | deny; default: allow) – specifies the action to perform on matched packets
allow – cache objects from matched request
deny – do not cache objects from matched request
dst-address (IP address/netmask) – destination address of the IP packet
dst-port (port{1,10}) – a list or range of ports the packet is destined to
local-port (port) – specifies the port of the web proxy via which the packet was received. This value should match one of the ports web proxy is listening on.
method (any | connect | delete | get | head | options | post | put | trace) – HTTP method used in the request (see HTTP Methods section in the end of this document)
path (wildcard) – name of the requested page within the target server (i.e. the name of a particular web page or document without the name of the server it resides on)
path (wildcard) – name of the requested page within the target server (i.e. the name of a particular web page or document without the name of the server it resides on)
src-address (IP address/netmask) – source address of the IP packet
Connection List
Submenu level: /ip proxy connections
Description
This menu contains the list of current connections the proxy is serving
Property Description
dst-address (read-only: IP address) – IP address of to which data are passed via this proxy
protocol (read-only: text) – protocol name
rx-bytes (read-only: integer) – the amount of bytes received from the remote end
src-address (read-only: IP address) – IP address of the remote end of the connection
state (read-only: connecting | idle | resolving | rx-body | rx-header | tx-body | tx-header | ) – opened connection state
connecting – establishing connection with server
idle – waiting for next client to serve
resolving – resolving server’s DNS name
rx-body – receiving HTTP body
rx-header – receiving HTTP header; or waiting for next request from client
tx-body – transmitting HTTP body
tx-header – transmitting HTTP header
tx-bytes (read-only: integer) – the amount of bytes sent to the remote end
Cache Contents
Submenu level: /ip proxy cache-contents
Description
This menu lists all the files stored in the cache
Property Description
file-size (read-only: integer) – size of the stored file
last-accessed (read-only: date) – date of the last access to the resource
last-accessed-time (read-only: time) – time of the last access to the resource
last-modified (read-only: date) – modification date
last-modified-time (read-only: time) – modification time
uri (read-only: text) – full resource name
Cache inserts
Submenu level: /ip proxy inserts
Description
This menu shows statistics on objects stored in cache (cache inserts)
Property Description
denied (read-only: integer) – number of inserts denied by the caching list
errors (read-only: integer) – number of disk or other system-related errors
no-memory (read-only: integer) – number of objects not stored because there was not enough memory
successes (read-only: integer) – number of successfull cache inserts
too-large (read-only: integer) – number of objects too large to store
Cache Lookups
Submenu level: /ip proxy lookups
Description
This menu shows statistics on objects read from cache (cache lookups)
Property Description
denied (read-only: integer) – number of requests denied by the access list
expired (read-only: integer) – number of requests found in cache, but expired, and, thus, requested from an external server
no-expiration-info (read-only: integer) – conditional request received for a page that does not have the information to compare the request with
non-cacheable (read-only: integer) – number of requests requested from the external servers unconditionally (as their caching is denied by the cache access list)
not-found (read-only: integer) – number of requests not found in the cache, and, thus, requested from an external server (or parent proxy if configured accordingly)
successes (read-only: integer) – number of requests found in the cache
Complementary Tools
Description
Web proxy has additional commands to handle non-system drive used for caching purposes and to recover the proxy from severe file system errors.
Command Description
check-drive – checks non-system cache drive for errors
clear-cache – deletes existing cache and creates new cache directories
format-drive – formats non-system cache drive and prepairs it for holding the cache
Transparent Mode
Description
Transparent proxy feature performs request caching invisibly to the end-user. This way the user does not notice that his connection is being processed by the proxy and therefore does not need to perform any additional configuration of the software he is using.
This feature may as well be combined with bridge to simplify deployment of web proxy in the existing infrastructure.
To enable the transparent mode, place a firewall rule in destination NAT, specifying which connections, id est traffic coming to which ports should be redirected to the proxy.
Notes
Only HTTP traffic is supported in transparent mode of the web proxy. HTTPS and FTP protocols are not going to work this way.
Example
To configure the router to transparently redirect all connections coming from ether1 interface to port 80 to the web proxy listening on port 8080, then add the following destination NAT rule:
[admin@MikroTik] > /ip firewall nat add in-interface=ether1 dst-port=80 \
\… protocol=tcp action=redirect to-ports=8080 chain=dstnat
[admin@MikroTik] > /ip firewall nat print
Flags: X – disabled, I – invalid, D – dynamic
0 chain=dstnat protocol=tcp in-interface=ether1 dst-port=80 action=redirect
to-ports=8080
[admin@MikroTik] >
Notes
Be aware, that you will not be able to access the router’s web page after addition of the rule above unless you will change the port for the www service under /ip service submenu to a different value or explicitly exclude router’s IP address from those to be matched, like:
/ip firewall nat add in-interface=ether1 dst-port=80 \
\… protocol=tcp action=redirect to-ports=8080 chain=dstnat dst-address=!1.1.1.1/32
It is assumed that the router’s address is 1.1.1.1/32.
HTTP Methods
Description
OPTIONS
This method is a request of information about the communication options available on the chain between the client and the server identified by the Request-URI. The method allows the client to determine the options and (or) the requirements associated with a resource without initiating any resource retrieval
GET
This method retrieves whatever information identified by the Request-URI. If the Request-URI refers to a data processing process than the response to the GET method should contain data produced by the process, not the source code of the process procedure(-s), unless the source is the result of the process.
The GET method can become a conditional GET if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. The conditional GET method is used to reduce the network traffic specifying that the transfer of the entity should occur only under circumstances described by conditional header field(-s).
The GET method can become a partial GET if the request message includes a Range header field. The partial GET method intends to reduce unnecessary network usage by requesting only parts of entities without transferring data already held by client.
The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching.
HEAD
This method shares all features of GET method except that the server must not return a message-body in the response. This retrieves the metainformation of the entity implied by the request which leads to a wide usage of it for testing hypertext links for validity, accessibility, and recent modification.
The response to a HEAD request may be cacheable in the way that the information contained in the response may be used to update previously cached entity identified by that Request-URI.
POST
This method requests that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI.
The actual action performed by the POST method is determined by the origin server and usually is Request-URI dependent.
Responses to POST method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.
PUT
This method requests that the enclosed entity be stored under the supplied Request-URI. If another entity exists under specified Request-URI, the enclosed entity should be considered as updated (newer) version of that residing on the origin server. If the Request-URI is not pointing to an existing resource, the origin server should create a resource with that URI.
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries should be treated as stale. Responses to this method are not cacheable.
TRACE
This method invokes a remote, application-layer loop-back of the request message. The final recipient of the request should reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of 0 in the request. A TRACE request must not include an entity.
Responses to this method MUST NOT be cached.
© Copyright 1999-2007, MikroTik. All rights reserved. Mikrotik, RouterOS and RouterBOARD are trademarks of Mikrotikls SIA. Other trademarks and registered trademarks mentioned herein are properties of their respective owners.
Home >
Documentation >
V3.0 >
IP Pools
PDF version

IP Pools
Document revision: 0.1 (January 14, 2008, 9:50 GMT)
Applies to: V3.0
General Information
Summary
IP pools are used to define range of IP addresses that is used for DHCP server and Point-to-Point servers
Specifications
Packages required: system
License required: Level1
Submenu level: /ip pool
Standards and Technologies: none
Hardware usage: Not significant
Description
IP pools simply group IP addresses for further usage. It is a single configuration point for all features that assign IP addresses to clients.
Notes
Whenever possible, the same ip address is given out to each client (OWNER/INFO pair).
Setup
Submenu level: /ip pool
Property Description
name (name) – the name of the pool
next-pool (name) – when address is acquired from pool that has no free addresses, and next-pool property is set to another pool, then next IP address will be acquired from next-pool
ranges (IP address) – IP address list of non-overlapping IP address ranges in form of: from1-to1,from2-to2,…,fromN-toN. For example, 10.0.0.1-10.0.0.27,10.0.0.32-10.0.0.47
Example
To define a pool named ip-pool with the 10.0.0.1-10.0.0.125 address range excluding gateway’s address 10.0.0.1 and server’s address 10.0.0.100, and the other pool dhcp-pool, with the 10.0.0.200-10.0.0.250 address range:
[admin@MikroTik] ip pool> add name=ip-pool ranges=10.0.0.2-10.0.0.99,10.0.0.101
10.0.0.126
[admin@MikroTik] ip pool> add name=dhcp-pool ranges=10.0.0.200-10.0.0.250
[admin@MikroTik] ip pool> print
# NAME RANGES
0 ip-pool 10.0.0.2-10.0.0.99
10.0.0.101-10.0.0.126
1 dhcp-pool 10.0.0.200-10.0.0.250

[admin@MikroTik] ip pool>
Used Addresses from Pool
Submenu level: /ip pool used
Description
Here you can see all used IP addresses from IP pools.
Property Description
address (read-only: IP address) – IP address that is assigned to client form the pool
info (read-only: name) – name of the interface to which the client is connected to
owner (read-only: MAC address) – MAC address of the client
pool (read-only: name) – name of the IP pool
Example
See used addresses from pool:
[admin@MikroTik] ip pool used> print
POOL ADDRESS OWNER INFO
local 192.168.0.100 00:0C:42:03:1F:60 test
local 192.168.0.99 00:0C:42:03:21:0F test
© Copyright 1999-2007, MikroTik. All rights reserved. Mikrotik, RouterOS and RouterBOARD are trademarks of Mikrotikls SIA. Other trademarks and registered trademarks mentioned herein are properties of their respective owners.

Home >
Documentation >
V3.0 >
SOCKS Proxy Server
PDF version

SOCKS Proxy Server
Document revision: 1.4 (January 14, 2008, 11:23 GMT)
Applies to: V3.0
General Information
Summary
This manual discusses the SOCKS proxy server which is implemented in RouterOS. MikroTik RouterOS supports SOCKS version 4.
Specifications
Packages required: system
License required: Level1
Submenu level: /ip socks
Standards and Technologies: SOCKS version 4
Hardware usage: Not significant
Description
SOCKS is a proxy server that allows TCP based application data to relay across the firewall, even if the firewall would block the packets. The SOCKS protocol is independent from application protocols, so it can be used for many services, e.g, WWW, FTP, TELNET, and others.
At first, an application client connects to the SOCKS proxy server, then the proxy server looks in its access list to see whether the client is permited to access the remote application resource or not, if it is permitted, the proxy server relies the packet to the application server and creates a connection between the application server and client.
Notes
Remember to configure your application client to use SOCKS version 4.
You should secure the SOCKS proxy using its access list and/or firewall to disallow access from outisde. Failing to secure the proxy server may introduce security issues to your network, and may provide a way for spammers to send junk mail through the router.
Additional Resources
• Information about SOCKS
SOCKS Configuration
Description
In this section you will learn how to enable the SOCKS proxy server and do its configuration.
Property Description
connection-idle-timeout (time; default: 2m) – time after which idle connections are terminated
enabled (yes | no; default: no) – whether to enable or no the SOCKS proxy
max-connections (integer: 1..500; default: 200) – maxumum number of simultaneous connections
port (integer: 1..65535; default: 1080) – TCP port on which the SOCKS server listens for connections
Example
To enable SOCKS:
[admin@MikroTik] ip socks> set enabled=yes
[admin@MikroTik] ip socks> print
enabled: yes
port: 1080
connection-idle-timeout: 2m
max-connections: 200
[admin@MikroTik] ip socks>
Access List
Submenu level: /ip socks access
Description
In the SOCKS access list you can add rules which will control access to SOCKS server. This list is similar to firewall lists.
Property Description
action (allow | deny; default: allow) – action to be performed for this rule
allow – allow packets, matching this rule, to be forwarded for further processing
deny – deny access for packets, matching this rule
dst-address (IP address/netmask) – destination (server’s) address
dst-port (port) – destination TCP port
src-address (IP address/netmask) – source (client’s) address for a packet
src-port (port) – source TCP port
Active Connections
Submenu level: /ip socks connections
Description
The Active Connection list shows all established TCP connections, which are maintained through the SOCKS proxy server.
Property Description
dst-address (read-only: IP address) – destination (application server) IP address
rx (read-only: integer) – bytes received
src-address (read-only: IP address) – source (application client) IP address
tx (read-only: integer) – bytes sent
type (read-only: in | out | unknown) – connection type
in – incoming connection
out – outgoing connection
unknown – connection has just been initiated
Example
To see current TCP connections:
[admin@MikroTik] ip socks connections> print
# SRC-ADDRESS DST-ADDRESS TX RX
0 192.168.0.2:3242 159.148.147.196:80 4847 2880
1 192.168.0.2:3243 159.148.147.196:80 3408 2127
2 192.168.0.2:3246 159.148.95.16:80 10172 25207
3 192.168.0.2:3248 194.8.18.26:80 474 1629
4 192.168.0.2:3249 159.148.95.16:80 6477 18695
5 192.168.0.2:3250 159.148.95.16:80 4137 27568
6 192.168.0.2:3251 159.148.95.16:80 1712 14296
7 192.168.0.2:3258 80.91.34.241:80 314 208
8 192.168.0.2:3259 80.91.34.241:80 934 524
9 192.168.0.2:3260 80.91.34.241:80 930 524
10 192.168.0.2:3261 80.91.34.241:80 312 158
11 192.168.0.2:3262 80.91.34.241:80 312 158
[admin@MikroTik] ip socks connections>
Application Examples
FTP service through SOCKS server
Let us consider that we have a network 192.168.0.0/24 which is masqueraded, using a router with a public IP 10.1.0.104/24 and a private IP 192.168.0.1/24. Somewhere in the network is an FTP server with IP address 10.5.8.8. We want to allow access to this FTP server for a client in our local network with IP address 192.168.0.2/24.
We have already masqueraded our local network:
[admin@MikroTik] ip firewall nat> print
Flags: X – disabled, I – invalid, D – dynamic
0 chain=srcnat action=masquerade src-address=192.168.0.0/24
[admin@MikroTik] ip firewall nat>
And the access to public FTP servers is denied in firewall:
[admin@MikroTik] ip firewall filter> print
Flags: X – disabled, I – invalid, D – dynamic
0 chain=forward action=drop src-address=192.168.0.0/24 dst-port=21 protocol=tcp
[admin@MikroTik] ip firewall filter>
We need to enable the SOCKS server:
[admin@MikroTik] ip socks> set enabled=yes
[admin@MikroTik] ip socks> print
enabled: yes
port: 1080
connection-idle-timeout: 2m
max-connections: 200
[admin@MikroTik] ip socks>
Add access to a client with an IP address 192.168.0.2/32 to SOCKS access list, allow data transfer from FTP server to client (allow destionation ports from 1024 to 65535 for any IP address), and drop everything else:
[admin@MikroTik] ip socks access> add src-address=192.168.0.2 dst-port=21 \
\… action=allow
[admin@MikroTik] ip socks access> add dst-port=1024-65535 action=allow
[admin@MikroTik] ip socks access> add action=deny
[admin@MikroTik] ip socks access> print
Flags: X – disabled
0 src-address=192.168.0.2 dst-port=21 action=allow
1 dst-port=1024-65535 action=allow
2 action=deny
[admin@MikroTik] ip socks access>
That’s all – the SOCKS server is configured. To see active connections and data transmitted and received:
[admin@MikroTik] ip socks connections> print
# SRC-ADDRESS DST-ADDRESS TX RX
0 192.168.0.2:1238 10.5.8.8:21 1163 4625
1 192.168.0.2:1258 10.5.8.8:3423 0 3231744
[admin@MikroTik] ip socks connections>
Note! In order to use SOCKS proxy server, you have to specify its IP address and port in your FTP client. In this case IP address would be 192.168.0.1 (local IP address of the router/SOCKS server) and TCP port 1080.
© Copyright 1999-2007, MikroTik. All rights reserved. Mikrotik, RouterOS and RouterBOARD are trademarks of Mikrotikls SIA. Other trademarks and registered trademarks mentioned herein are properties of their respective owners.
Home >
Documentation >
V3.0 >
UPnP
PDF version

UPnP
Document revision: 2.3 (January 14, 2008, 11:56 GMT)
Applies to: V3.0
General Information
Summary
The MikroTik RouterOS supports Universal Plug and Play architecture for transparent peer-to-peer network connectivity of personal computers and network-enabled intelligent devices or appliances. UPnP builds enables these devices to automatically connect with one another and work together to make networking possible for more people.
Specifications
Packages required: system
License required: Level1
Submenu level: /ip upnp
Standards and Technologies: TCP/IP, HTTP, XML, IGD
Hardware usage: Not significant
Description
UPnP enables data communication between any two devices under the command of any control device on the network. Universal Plug and Play is completely independent of any particular physical medium. It supports networking with automatic discovery without any initial configuration, whereby a device can dynamically join a network. DHCP and DNS servers are optional and will be used if available on the network. UPnP implements simple yet powerfull NAT traversal solution, that enables the client to get full two-way peer-to-peer network support from behind the NAT.
There are two interface types for UPnP: internal (the one local clients are connected to) and external (the one the Internet is connected to). A router may only have one external interface with a ‘public’ IP address on it, and as many internal interfaces as needed, all with source-NATted ‘internal’ IP addresses.
The UPnP protocol is used for many modern applications, like most of DirectX games, as well as for various Windows Messenger features (remote asisstance, application sharing, file transfer, voice, video) from behind a firewall.
Additional Resources
UPnP Forum
Enabling Universal Plug-n-Play
Submenu level: /ip upnp
Property Description
allow-disable-external-interface (yes | no; default: yes) – whether or not should the users be allowed to disable router’s external interface. This functionality (for users to be able to turn the router’s external interface off without any authentication procedure) is required by the standard, but as it is sometimes not expected or unwanted in UPnP deployments which the standard was not designed for (it was designed mostly for home users to establish their ownlocal networks), you can disable this behavior
enabled (yes | no; default: no) – whether UPnP feature is enabled
show-dummy-rule (yes | no; default: yes) – this is to enable a workaround for some broken implementations, which are handling the absense of UPnP rules incorrectly (for example, popping up error messages). This option will instruct the server to install a dummy (meaningless) UPnP rule that can be observed by the clients, which refuse to work correctly otherwise
Notes
CAUTION: if you do not disable the allow-disable-external-interface, any user from the local network will be able (without any authentication procedures) to disable the router’s external interface.
Example
To enable UPnP feature:
[admin@MikroTik] ip upnp> set enable=yes
[admin@MikroTik] ip upnp> print
enabled: yes
allow-disable-external-interface: yes
show-dummy-rule: yes
[admin@MikroTik] ip upnp>

UPnP Interfaces
Submenu level: /ip upnp interfaces
Property Description
interface (name) – interface name UPnP will be run on
type (external | internal) – interface type, one of the:
external – the interface a global IP address is assigned to
internal – router’s local interface the clients are connected to
Notes
It is highly recommended to upgrade DirectX runtime libraries to version DirectX 9.0c or higher and Windows Messenger to version Windows Messenger 5.0 or higher in order to get UPnP to work properly.
Example

We have masquerading already enabled on our router:
[admin@MikroTik] ip upnp interfaces> /ip firewall src-nat print
Flags: X – disabled, I – invalid, D – dynamic
0 chain=srcnat action=masquerade out-interface=ether1
[admin@MikroTik] ip upnp interfaces>

Now all we have to do is to add interfaces and enable UPnP:
[admin@MikroTik] ip upnp interfaces> add interface=ether1 type=external
[admin@MikroTik] ip upnp interfaces> add interface=ether2 type=internal
[admin@MikroTik] ip upnp interfaces> print
Flags: X – disabled
# INTERFACE TYPE
0 X ether1 external
1 X ether2 internal

[admin@MikroTik] ip upnp interfaces> enable 0,1
[admin@MikroTik] ip upnp interfaces> .. set enabled=yes
[admin@MikroTik] ip upnp interfaces>

© Copyright 1999-2007, MikroTik. All rights reserved. Mikrotik, RouterOS and RouterBOARD are trademarks of Mikrotikls SIA. Other trademarks and registered trademarks mentioned herein are properties of their respective owners.

Firewall


Ilustrasi mengenai Firewall
Firewall atau tembok-api adalah sebuah sistem atau perangkat yang mengizinkan lalu lintas jaringan yang dianggap aman untuk melaluinya dan mencegah lalu lintas jaringan yang tidak aman. Umumnya, sebuah tembok-api diterapkan dalam sebuah mesin terdedikasi, yang berjalan pada pintu gerbang (gateway) antara jaringan lokal dan jaringan lainnya. Tembok-api umumnya juga digunakan untuk mengontrol akses terhadap siapa saja yang memiliki akses terhadap jaringan pribadi dari pihak luar. Saat ini, istilah firewall menjadi istilah lazim yang merujuk pada sistem yang mengatur komunikasi antar dua jaringan yang berbeda. Mengingat saat ini banyak perusahaan yang memiliki akses ke Internet dan juga tentu saja jaringan berbadan hukum di dalamnya, maka perlindungan terhadap modal digital perusahaan tersebut dari serangan para peretas, pemata-mata, ataupun pencuri data lainnya, menjadi hakikat.
Jenis-jenis Firewall

Taksonomi Firewall
Firewall terbagi menjadi dua jenis, yakni sebagai berikut
• Personal Firewall: Personal Firewall didesain untuk melindungi sebuah komputer yang terhubung ke jaringan dari akses yang tidak dikehendaki. Firewall jenis ini akhir-akhir ini berevolusi menjadi sebuah kumpulan program yang bertujuan untuk mengamankan komputer secara total, dengan ditambahkannya beberapa fitur pengaman tambahan semacam perangkat proteksi terhadap virus, anti-spyware, anti-spam, dan lainnya. Bahkan beberapa produk firewall lainnya dilengkapi dengan fungsi pendeteksian gangguan keamanan jaringan (Intrusion Detection System). Contoh dari firewall jenis ini adalah Microsoft Windows Firewall (yang telah terintegrasi dalam sistem operasi Windows XP Service Pack 2, Windows Vista dan Windows Server 2003 Service Pack 1), Symantec Norton Personal Firewall, Kerio Personal Firewall, dan lain-lain. Personal Firewall secara umum hanya memiliki dua fitur utama, yakni Packet Filter Firewall dan Stateful Firewall.
• Network Firewall: Network ‘‘’’Firewall didesain untuk melindungi jaringan secara keseluruhan dari berbagai serangan. Umumnya dijumpai dalam dua bentuk, yakni sebuah perangkat terdedikasi atau sebagai sebuah perangkat lunak yang diinstalasikan dalam sebuah server. Contoh dari firewall ini adalah Microsoft Internet Security and Acceleration Server (ISA Server), Cisco PIX, Cisco ASA, IPTables dalam sistem operasi GNU/Linux, pf dalam keluarga sistem operasi Unix BSD, serta SunScreen dari Sun Microsystems, Inc. yang dibundel dalam sistem operasi Solaris. Network Firewall secara umum memiliki beberapa fitur utama, yakni apa yang dimiliki oleh personal firewall (packet filter firewall dan stateful firewall), Circuit Level Gateway, Application Level Gateway, dan juga NAT Firewall. Network Firewall umumnya bersifat transparan (tidak terlihat) dari pengguna dan menggunakan teknologi routing untuk menentukan paket mana yang diizinkan, dan mana paket yang akan ditolak.
Fungsi Firewall
Secara fundamental, firewall dapat melakukan hal-hal berikut:
• Mengatur dan mengontrol lalu lintas jaringan
• Melakukan autentikasi terhadap akses
• Melindungi sumber daya dalam jaringan privat
• Mencatat semua kejadian, dan melaporkan kepada administrator
Mengatur dan Mengontrol Lalu lintas jaringan
Fungsi pertama yang dapat dilakukan oleh firewall adalah firewall harus dapat mengatur dan mengontrol lalu lintas jaringan yang diizinkan untuk mengakses jaringan privat atau komputer yang dilindungi oleh firewall. Firewall melakukan hal yang demikian, dengan melakukan inspeksi terhadap paket-paket dan memantau koneksi yang sedang dibuat, lalu melakukan penapisan (filtering) terhadap koneksi berdasarkan hasil inspeksi paket dan koneksi tersebut.
Proses inspeksi Paket
Inspeksi paket (‘packet inspection) merupakan proses yang dilakukan oleh firewall untuk ‘menghadang’ dan memproses data dalam sebuah paket untuk menentukan bahwa paket tersebut diizinkan atau ditolak, berdasarkan kebijakan akses (access policy) yang diterapkan oleh seorang administrator. Firewall, sebelum menentukan keputusan apakah hendak menolak atau menerima komunikasi dari luar, ia harus melakukan inspeksi terhadap setiap paket (baik yang masuk ataupun yang keluar) di setiap antarmuka dan membandingkannya dengan daftar kebijakan akses. Inspeksi paket dapat dilakukan dengan melihat elemen-elemen berikut, ketika menentukan apakah hendak menolak atau menerima komunikasi:
• Alamat IP dari komputer sumber
• Port sumber pada komputer sumber
• Alamat IP dari komputer tujuan
• Port tujuan data pada komputer tujuan
• Protokol IP
• Informasi header-header yang disimpan dalam paket
Koneksi dan Keadaan Koneksi
Agar dua host TCP/IP dapat saling berkomunikasi, mereka harus saling membuat koneksi antara satu dengan lainnya. Koneksi ini memiliki dua tujuan:
1. Komputer dapat menggunakan koneksi tersebut untuk mengidentifikasikan dirinya kepada komputer lain, yang meyakinkan bahwa sistem lain yang tidak membuat koneksi tidak dapat mengirimkan data ke komputer tersebut. Firewall juga dapat menggunakan informasi koneksi untuk menentukan koneksi apa yang diizinkan oleh kebijakan akses dan menggunakannya untuk menentukan apakah paket data tersebut akan diterima atau ditolak.
2. Koneksi digunakan untuk menentukan bagaimana cara dua host tersebut akan berkomunikasi antara satu dengan yang lainnya (apakah dengan menggunakan koneksi connection-oriented, atau connectionless).

Ilustrasi mengenai percakapan antara dua buah host
Kedua tujuan tersebut dapat digunakan untuk menentukan keadaan koneksi antara dua host tersebut, seperti halnya cara manusia bercakap-cakap. Jika Amir bertanya kepada Aminah mengenai sesuatu, maka Aminah akan meresponsnya dengan jawaban yang sesuai dengan pertanyaan yang diajukan oleh Amir; Pada saat Amir melontarkan pertanyaannya kepada Aminah, keadaan percakapan tersebut adalah Amir menunggu respons dari Aminah. Komunikasi di jaringan juga mengikuti cara yang sama untuk memantau keadaan percakapan komunikasi yang terjadi.
Firewall dapat memantau informasi keadaan koneksi untuk menentukan apakah ia hendak mengizinkan lalu lintas jaringan. Umumnya hal ini dilakukan dengan memelihara sebuah tabel keadaan koneksi (dalam istilah firewall: state table) yang memantau keadaan semua komunikasi yang melewati firewall. Dengan memantau keadaan koneksi ini, firewall dapat menentukan apakah data yang melewati firewall sedang “ditunggu” oleh host yang dituju, dan jika ya, aka mengizinkannya. Jika data yang melewati firewall tidak cocok dengan keadaan koneksi yang didefinisikan oleh tabel keadaan koneksi, maka data tersebut akan ditolak. Hal ini umumnya disebut sebagai Stateful Inspection.
Stateful Packet Inspection
Ketika sebuah firewall menggabungkan stateful inspection dengan packet inspection, maka firewall tersebut dinamakan dengan Stateful Packet Inspection (SPI). SPI merupakan proses inspeksi paket yang tidak dilakukan dengan menggunakan struktur paket dan data yang terkandung dalam paket, tapi juga pada keadaan apa host-host yang saling berkomunikasi tersebut berada. SPI mengizinkan firewall untuk melakukan penapisan tidak hanya berdasarkan isi paket tersebut, tapi juga berdasarkan koneksi atau keadaan koneksi, sehingga dapat mengakibatkan firewall memiliki kemampuan yang lebih fleksibel, mudah diatur, dan memiliki skalabilitas dalam hal penapisan yang tinggi.
Salah satu keunggulan dari SPI dibandingkan dengan inspeksi paket biasa adalah bahwa ketika sebuah koneksi telah dikenali dan diizinkan (tentu saja setelah dilakukan inspeksi), umumnya sebuah kebijakan (policy) tidak dibutuhkan untuk mengizinkan komunikasi balasan karena firewall tahu respons apa yang diharapkan akan diterima. Hal ini memungkinkan inspeksi terhadap data dan perintah yang terkandung dalam sebuah paket data untuk menentukan apakah sebuah koneksi diizinkan atau tidak, lalu firewall akan secara otomatis memantau keadaan percakapan dan secara dinamis mengizinkan lalu lintas yang sesuai dengan keadaan. Ini merupakan peningkatan yang cukup signifikan jika dibandingkan dengan firewall dengan inspeksi paket biasa. Apalagi, proses ini diselesaikan tanpa adanya kebutuhan untuk mendefinisikan sebuah kebijakan untuk mengizinkan respons dan komunikasi selanjutnya. Kebanyakan firewall modern telah mendukung fungsi ini.
Melakukan autentikasi terhadap akses
Fungsi fundamental firewall yang kedua adalah firewall dapat melakukan autentikasi terhadap akses.
Protokol TCP/IP dibangun dengan premis bahwa protokol tersebut mendukung komunikasi yang terbuka. Jika dua host saling mengetahui alamat IP satu sama lainnya, maka mereka diizinkan untuk saling berkomunikasi. Pada awal-awal perkembangan Internet, hal ini boleh dianggap sebagai suatu berkah. Tapi saat ini, di saat semakin banyak yang terhubung ke Internet, mungkin kita tidak mau siapa saja yang dapat berkomunikasi dengan sistem yang kita miliki. Karenanya, firewall dilengkapi dengan fungsi autentikasi dengan menggunakan beberapa mekanisme autentikasi, sebagai berikut:
• Firewall dapat meminta input dari pengguna mengenai nama pengguna (user name) serta kata kunci (password). Metode ini sering disebut sebagai extended authentication atau xauth. Menggunakan xauth pengguna yang mencoba untuk membuat sebuah koneksi akan diminta input mengenai nama dan kata kuncinya sebelum akhirnya diizinkan oleh firewall. Umumnya, setelah koneksi diizinkan oleh kebijakan keamanan dalam firewall, firewall pun tidak perlu lagi mengisikan input password dan namanya, kecuali jika koneksi terputus dan pengguna mencoba menghubungkan dirinya kembali.
• Metode kedua adalah dengan menggunakan sertifikat digital dan kunci publik. Keunggulan metode ini dibandingkan dengan metode pertama adalah proses autentikasi dapat terjadi tanpa intervensi pengguna. Selain itu, metode ini lebih cepat dalam rangka melakukan proses autentikasi. Meskipun demikian, metode ini lebih rumit implementasinya karena membutuhkan banyak komponen seperti halnya implementasi infrastruktur kunci publik.
• Metode selanjutnya adalah dengan menggunakan Pre-Shared Key (PSK) atau kunci yang telah diberitahu kepada pengguna. Jika dibandingkan dengan sertifikat digital, PSK lebih mudah diimplenentasikan karena lebih sederhana, tetapi PSK juga mengizinkan proses autentikasi terjadi tanpa intervensi pengguna. Dengan menggunakan PSK, setiap host akan diberikan sebuah kunci yang telah ditentukan sebelumnya yang kemudian digunakan untuk proses autentikasi. Kelemahan metode ini adalah kunci PSK jarang sekali diperbarui dan banyak organisasi sering sekali menggunakan kunci yang sama untuk melakukan koneksi terhadap host-host yang berada pada jarak jauh, sehingga hal ini sama saja meruntuhkan proses autentikasi. Agar tercapai sebuah derajat keamanan yang tinggi, umumnya beberapa organisasi juga menggunakan gabungan antara metode PSK dengan xauth atau PSK dengan sertifikat digital.
Dengan mengimplementasikan proses autentikasi, firewall dapat menjamin bahwa koneksi dapat diizinkan atau tidak. Meskipun jika paket telah diizinkan dengan menggunakan inspeksi paket (PI) atau berdasarkan keadaan koneksi (SPI), jika host tersebut tidak lolos proses autentikasi, paket tersebut akan dibuang.
Melindungi sumber daya dalam jaringan privat
Salah satu tugas firewall adalah melindungi sumber daya dari ancaman yang mungkin datang. Proteksi ini dapat diperoleh dengan menggunakan beberapa peraturan pengaturan akses (access control), penggunaan SPI, application proxy, atau kombinasi dari semuanya untuk mencegah host yang dilindungi dapat diakses oleh host-host yang mencurigakan atau dari lalu lintas jaringan yang mencurigakan. Meskipun demikian, firewall bukanlah satu-satunya metode proteksi terhadap sumber daya, dan mempercayakan proteksi terhadap sumber daya dari ancaman terhadap firewall secara eksklusif adalah salah satu kesalahan fatal. Jika sebuah host yang menjalankan sistem operasi tertentu yang memiliki lubang keamanan yang belum ditambal dikoneksikan ke Internet, firewall mungkin tidak dapat mencegah dieksploitasinya host tersebut oleh host-host lainnya, khususnya jika exploit tersebut menggunakan lalu lintas yang oleh firewall telah diizinkan (dalam konfigurasinya). Sebagai contoh, jika sebuah packet-inspection firewall mengizinkan lalu lintas HTTP ke sebuah web server yang menjalankan sebuah layanan web yang memiliki lubang keamanan yang belum ditambal, maka seorang pengguna yang “iseng” dapat saja membuat exploit untuk meruntuhkan web server tersebut karena memang web server yang bersangkutan memiliki lubang keamanan yang belum ditambal. Dalam contoh ini, web server tersebut akhirnya mengakibatkan proteksi yang ditawarkan oleh firewall menjadi tidak berguna. Hal ini disebabkan oleh firewall yang tidak dapat membedakan antara request HTTP yang mencurigakan atau tidak. Apalagi, jika firewall yang digunakan bukan application proxy. Oleh karena itulah, sumber daya yang dilindungi haruslah dipelihara dengan melakukan penambalan terhadap lubang-lubang keamanan, selain tentunya dilindungi oleh firewall.

Mencatat semua kejadian, dan melaporkan kepada administrator
[Placeholder]
Cara Kerja Firewall
Packet-Filter Firewall

Contoh pengaturan akses (access control) yang diterapkan dalam firewall
Pada bentuknya yang paling sederhana, sebuah firewall adalah sebuah router atau komputer yang dilengkapi dengan dua buah NIC (Network Interface Card, kartu antarmuka jaringan) yang mampu melakukan penapisan atau penyaringan terhadap paket-paket yang masuk. Perangkat jenis ini umumnya disebut dengan packet-filtering router.
Firewall jenis ini bekerja dengan cara membandingkan alamat sumber dari paket-paket tersebut dengan kebijakan pengontrolan akses yang terdaftar dalam Access Control List firewall, router tersebut akan mencoba memutuskan apakah hendak meneruskan paket yang masuk tersebut ke tujuannya atau menghentikannya. Pada bentuk yang lebih sederhana lagi, firewall hanya melakukan pengujian terhadap alamat IP atau nama domain yang menjadi sumber paket dan akan menentukan apakah hendak meneruskan atau menolak paket tersebut. Meskipun demikian, packet-filtering router tidak dapat digunakan untuk memberikan akses (atau menolaknya) dengan menggunakan basis hak-hak yang dimiliki oleh pengguna.

Cara kerja packet filter firewall
Packet-filtering router juga dapat dikonfigurasikan agar menghentikan beberapa jenis lalu lintas jaringan dan tentu saja mengizinkannya. Umumnya, hal ini dilakukan dengan mengaktifkan/menonaktifkan port TCP/IP dalam sistem firewall tersebut. Sebagai contoh, port 25 yang digunakan oleh Protokol SMTP (Simple Mail Transfer Protocol) umumnya dibiarkan terbuka oleh beberapa firewall untuk mengizinkan surat elektronik dari Internet masuk ke dalam jaringan privat, sementara port lainnya seperti port 23 yang digunakan oleh Protokol Telnet dapat dinonaktifkan untuk mencegah pengguna Internet untuk mengakses layanan yang terdapat dalam jaringan privat tersebut. Firewall juga dapat memberikan semacam pengecualian (exception) agar beberapa aplikasi dapat melewati firewall tersebut. Dengan menggunakan pendekatan ini, keamanan akan lebih kuat tapi memiliki kelemahan yang signifikan yakni kerumitan konfigurasi terhadap firewall: daftar Access Control List firewall akan membesar seiring dengan banyaknya alamat IP, nama domain, atau port yang dimasukkan ke dalamnya, selain tentunya juga exception yang diberlakukan.
Circuit Level Gateway

Cara kerja circuit level firewall
Firewall jenis lainnya adalah Circuit-Level Gateway, yang umumnya berupa komponen dalam sebuah proxy server. Firewall jenis ini beroperasi pada level yang lebih tinggi dalam model referensi tujuh lapis OSI (bekerja pada lapisan sesi/session layer) daripada Packet Filter Firewall. Modifikasi ini membuat firewall jenis ini berguna dalam rangka menyembunyikan informasi mengenai jaringan terproteksi, meskipun firewall ini tidak melakukan penyaringan terhadap paket-paket individual yang mengalir dalam koneksi.
Dengan menggunakan firewall jenis ini, koneksi yang terjadi antara pengguna dan jaringan pun disembunyikan dari pengguna. Pengguna akan dihadapkan secara langsung dengan firewall pada saat proses pembuatan koneksi dan firewall pun akan membentuk koneksi dengan sumber daya jaringan yang hendak diakses oleh pengguna setelah mengubah alamat IP dari paket yang ditransmisikan oleh dua belah pihak. Hal ini mengakibatkan terjadinya sebuah sirkuit virtual (virtual circuit) antara pengguna dan sumber daya jaringan yang ia akses.
Firewall ini dianggap lebih aman dibandingkan dengan Packet-Filtering Firewall, karena pengguna eksternal tidak dapat melihat alamat IP jaringan internal dalam paket-paket yang ia terima, melainkan alamat IP dari firewall. Protokol yang populer digunakan sebagai Circuit-Level Gateway adalah SOCKS v5.
Application Level Firewall

Application Level Firewall (disebut juga sebagai application proxy atau application level gateway)
Firewall jenis lainnya adalah Application Level Gateway (atau Application-Level Firewall atau sering juga disebut sebagai Proxy Firewall), yang umumnya juga merupakan komponen dari sebuah proxy server. Firewall ini tidak mengizinkan paket yang datang untuk melewati firewall secara langsung. Tetapi, aplikasi proxy yang berjalan dalam komputer yang menjalankan firewall akan meneruskan permintaan tersebut kepada layanan yang tersedia dalam jaringan privat dan kemudian meneruskan respons dari permintaan tersebut kepada komputer yang membuat permintaan pertama kali yang terletak dalam jaringan publik yang tidak aman.
Umumnya, firewall jenis ini akan melakukan autentikasi terlebih dahulu terhadap pengguna sebelum mengizinkan pengguna tersebut untuk mengakses jaringan. Selain itu, firewall ini juga mengimplementasikan mekanisme auditing dan pencatatan (logging) sebagai bagian dari kebijakan keamanan yang diterapkannya. Application Level Firewall juga umumnya mengharuskan beberapa konfigurasi yang diberlakukan pada pengguna untuk mengizinkan mesin klien agar dapat berfungsi. Sebagai contoh, jika sebuah proxy FTP dikonfigurasikan di atas sebuah application layer gateway, proxy tersebut dapat dikonfigurasikan untuk mengizinlan beberapa perintah FTP, dan menolak beberapa perintah lainnya. Jenis ini paling sering diimplementasikan pada proxy SMTP sehingga mereka dapat menerima surat elektronik dari luar (tanpa menampakkan alamat e-mail internal), lalu meneruskan e-mail tersebut kepada e-mail server dalam jaringan. Tetapi, karena adanya pemrosesan yang lebih rumit, firewall jenis ini mengharuskan komputer yang dikonfigurasikan sebagai application gateway memiliki spesifikasi yang tinggi, dan tentu saja jauh lebih lambat dibandingkan dengan packet-filter firewall.
NAT Firewall
NAT (Network Address Translation) Firewall secara otomatis menyediakan proteksi terhadap sistem yang berada di balik firewall karena NAT Firewall hanya mengizinkan koneksi yang datang dari komputer-komputer yang berada di balik firewall. Tujuan dari NAT adalah untuk melakukan multiplexing terhadap lalu lintas dari jaringan internal untuk kemudian menyampaikannya kepada jaringan yang lebih luas (MAN, WAN atau Internet) seolah-olah paket tersebut datang dari sebuah alamat IP atau beberapa alamat IP. NAT Firewall membuat tabel dalam memori yang mengandung informasi mengenai koneksi yang dilihat oleh firewall. Tabel ini akan memetakan alamat jaringan internal ke alamat eksternal. Kemampuan untuk menaruh keseluruhan jaringan di belakang sebuah alamat IP didasarkan terhadap pemetaan terhadap port-port dalam NAT firewall.
Lihat juga: Network Address Translation

Stateful Firewall

Cara kerja stateful firewall
Stateful Firewall merupakan sebuah firewall yang menggabungkan keunggulan yang ditawarkan oleh packet-filtering firewall, NAT Firewall, Circuit-Level Firewall dan Proxy Firewall dalam satu sistem. Stateful Firewall dapat melakukan filtering terhadap lalu lintas berdasarkan karakteristik paket, seperti halnya packet-filtering firewall, dan juga memiliki pengecekan terhadap sesi koneksi untuk meyakinkan bahwa sesi koneksi yang terbentuk tersebut diizinlan. Tidak seperti Proxy Firewall atau Circuit Level Firewall, Stateful Firewall umumnya didesain agar lebih transparan (seperti halnya packet-filtering firewall atau NAT firewall). Tetapi, stateful firewall juga mencakup beberapa aspek yang dimiliki oleh application level firewall, sebab ia juga melakukan inspeksi terhadap data yang datang dari lapisan aplikasi (application layer) dengan menggunakan layanan tertentu. Firewall ini hanya tersedia pada beberapa firewall kelas atas, semacam Cisco PIX. Karena menggabungkan keunggulan jenis-jenis firewall lainnya, stateful firewall menjadi lebih kompleks.

Virtual Firewall
Virtual Firewall adalah sebutan untuk beberapa firewall logis yang berada dalam sebuah perangkat fisik (komputer atau perangkat firewall lainnya). Pengaturan ini mengizinkan beberapa jaringan agar dapat diproteksi oleh sebuah firewall yang unik yang menjalankan kebijakan keamanan yang juga unik, cukup dengan menggunakan satu buah perangkat. Dengan menggunakan firewall jenis ini, sebuah ISP (Internet Service Provider) dapat menyediakan layanan firewall kepada para pelanggannya, sehingga mengamankan lalu lintas jaringan mereka, hanya dengan menggunakan satu buah perangkat. Hal ini jelas merupakan penghematan biaya yang signifikan, meski firewall jenis ini hanya tersedia pada firewall kelas atas, seperti Cisco PIX 535.
Transparent Firewall
Transparent Firewall (juga dikenal sebagai bridging firewall) bukanlah sebuah firewall yang murni, tetapi ia hanya berupa turunan dari stateful Firewall. Daripada firewall-firewall lainnya yang beroperasi pada lapisan IP ke atas, transparent firewall bekerja pada lapisan Data-Link Layer, dan kemudian ia memantau lapisan-lapisan yang ada di atasnya. Selain itu, transparent firewall juga dapat melakukan apa yang dapat dilakukan oleh packet-filtering firewall, seperti halnya stateful firewall dan tidak terlihat oleh pengguna (karena itulah, ia disebut sebagai Transparent Firewall).
Intinya, transparent firewall bekerja sebagai sebuah bridge yang bertugas untuk menyaring lalu lintas jaringan antara dua segmen jaringan. Dengan menggunakan transparent firewall, keamanan sebuah segmen jaringan pun dapat diperkuat, tanpa harus mengaplikasikan NAT Filter. Transparent Firewall menawarkan tiga buah keuntungan, yakni sebagai berikut:
• Konfigurasi yang mudah (bahkan beberapa produk mengklaim sebagai “Zero Configuration”). Hal ini memang karena transparent firewall dihubungkan secara langsung dengan jaringan yang hendak diproteksinya, dengan memodifikasi sedikit atau tanpa memodifikasi konfigurasi firewall tersebut. Karena ia bekerja pada data-link layer, pengubahan alamat IP pun tidak dibutuhkan. Firewall juga dapat dikonfigurasikan untuk melakukan segmentasi terhadap sebuah subnet jaringan antara jaringan yang memiliki keamanan yang rendah dan keamanan yang tinggi atau dapat juga untuk melindungi sebuah host, jika memang diperlukan.
• Kinerja yang tinggi. Hal ini disebabkan oleh firewall yang berjalan dalam lapisan data-link lebih sederhana dibandingkan dengan firewall yang berjalan dalam lapisan yang lebih tinggi. Karena bekerja lebih sederhana, maka kebutuhan pemrosesan pun lebih kecil dibandingkan dengan firewall yang berjalan pada lapisan yang tinggi, dan akhirnya performa yang ditunjukannya pun lebih tinggi.
• Tidak terlihat oleh pengguna (stealth). Hal ini memang dikarenakan Transparent Firewall bekerja pada lapisan data-link, dan tidak membutuhkan alamat IP yang ditetapkan untuknya (kecuali untuk melakukan manajemen terhadapnya, jika memang jenisnya managed firewall). Karena itulah, transparent firewall tidak dapat terlihat oleh para penyerang. Karena tidak dapat diraih oleh penyerang (tidak memiliki alamat IP), penyerang pun tidak dapat menyerangnya.

Konsep Konfigurasi Switch


Switch adalah perangkat jaringan yang bekerja pada Layer 2 OSI (data link) yang berfungsi sebagai titik konsentrasi untuk perangkat-perangkat lain yang terhubung seperti komputer, server, router, hub, dan switch lainnya. Pada awalnya hub adalah perangkat konsentrasi yang menyediakan beberapa port yang mirip dengan switch. Akan tetapi dengan hub seluruh komputer yang terhubung akan berbagi bandwidth bersama (shared-bandwidth) dan collision dapat terjadi. Hub beroperasi secara half-duplex (hanya dapat mengirim atau menerima pada suatu waktu) karena hub harus mampu mendeteksi collision. Switch menyediakan koneksi point-to-point terdedikasi (virtual circuit) antara dua perangkat jaringan (seperti komputer, server, router) sehingga tidak terjadi collision. Karena switch tidak perlu mendeteksi collision, maka switch dapat beroperasi secara full-duplex (mengirim dan menerima secara simultan) yang akan melipatgandakan throughput-nya. Switch-switch Ethernet tersedia dengan berbagai kecepatan yaitu 10Mbps (standard Ethernet), 100Mbps (Fast Ethernet) and 1000Mbps (Gigabit Ethernet).

Dengan kemampuan switch tersebut, pembangunan VLAN ( Virtual Local Area Network ) dapat dilakukan. Dengan VLAN, komputer yang tergabung tidak harus berada pada satu daerah yang sama. Berlandaskan pada keinginan tersebut, maka upaya-upaya penyempurnaan terus dilakukan oleh berbagai pihak. Dengan memanfaatkan berbagai teknik khususnya teknik subnetting dan penggunaan hardware yang lebih baik (antara lain switch) maka muncullah konsep VLAN yang diharapkan memberikan hasil yang lebih baik dibanding LAN.

Konfigurasi Umum Switch

Penggunaan switch pada jaringan akan membuat jaringan tersebut lebih handal dan terasa lebih cepat. Switch yang baru dibeli dan langsung dipasang akan segera bekerja seperti seharusnya. Ada beberapa konfigurasi umum yang dilakukan oleh administrator jaringan, yaitu :

* Mengganti nama switch

Untuk mengganti nama switch, digunakan perintah hostname, seperti :

Switch>enable
Switch#configure terminal
Switch(config)#hostname ganti
ganti(config)#

* Membuat password pada switch

Ada dua cara untuk membuat password pada switch, yaitu dengan enable password dan enable secret. Perbedaan pada kedua perintah itu adalah enable password tidak dienkripsi dan enable secret dienkripsi. Contoh konfigurasinya :

ganti(config)#enable password tekkom
ganti(config)#enable secret teknik komputer

jika kedua perintah ini dikonfigurasi pada switch, maka yang akan digunakan sebagai password pada switch adalah perintah enable secret.

* Mengkonfigurasi interface

Perintah yang digunakan untuk melakukan konfigurasi pada interface yang ada pada switch dengan perintah interface, seperti :

ganti(config)#interface fastEthernet 0/3
ganti(config-if)#

source : http://tulisanku.com/

Pengertian VLAN


Sebuah Virtual LAN merupakan fungsi logik dari sebuah switch. Fungsi logik ini mampu membagi jaringan LAN ke dalam beberapa jaringan virtual. Jaringan virtual ini tersambung ke dalam perangkat fisik yang sama. Implementasi VLAN dalam jaringan memudahkan seorang administrator dalam membagi secara logik kelompok-kelompok komputer secara fungsional dan tidak dibatasi oleh lokasi. VLAN dikembangkan sebagai pilihan alternatif untuk mengurangi broadcast traffic.

Pada tradisional LAN, collision sering sekali terjadi. Collision adalah tabrakan antar paket-paket yang dikirimkan oleh 2 pengguna atau lebih pada saat yang bersamaan. Untuk mengatasi collision pada sebuah jaringan, maka digunakan sebuah bridge atau switch. Perangkat ini tidak akan mem-forward collision, tapi bisa melewatkan broadcast (ke setiap pengguna di jaringan) dan multicast. Dan sebuah router digunakan untuk mencegah broadcast dan multicast dari lalu lintas data jaringan.

VLAN merupakan suatu model jaringan yang tidak terbatas pada lokasi fisik seperti LAN. Hal ini mengakibatkan suatu jaringan dapat dikonfigurasi secara virtual tanpa harus menuruti lokasi fisik peralatan. Penggunaan VLAN membuat pengaturan jaringan menjadi sangat fleksibel tanpa tergantung pada lokasi peralatan.

Contoh Konfigurasi Switch dan Router buat VLAN


Dibawah ini adalah contoh konfigurasi sederhana untuk membuat sebuah jaringan yang terdiri dari 4 VLAN dan bisa berkomunikasi antar jaringan melalui bantuan router.

Konfigurasi Switch

Konfigurasi switch disesuaikan dengan kebutuhan jaringan yang ada, yaitu membuat 4 buah VLAN. VLAN-VLAN lainnya bisa ditambahkan sesuai kebutuhan jaringan. Konfigurasi yang dibuat adalah seperti berikut :

* Membuat VLAN.
Switch#vlan database
Switch(vlan)#vlan 10 name VLAN1
Switch(vlan)#vlan 20 name VLAN2
Switch(vlan)#vlan 30 name VLAN3
Switch(vlan)#vlan 40 name VLAN4
Switch(vlan)#exit
* Menentukan port sebagai trunk dan setting enkapsulasinya.
Switch#config terminal
Switch(config)#interface fastethernet 0/12
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#exit
* Menentukan port untuk tiap VLAN dan port access-nya.
Switch(config)#interface fastethernet 0/2
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 10
* Memverifikasi pengaturan switch.
Switch#show vlan ==> Lihat semua VLAN yang ada.
Switch#show vlan [number] ==> Lihat VLAN berdasarkan ID.
Switch#show running-config ==> Lihat hasil konfigurasi.

Konfigurasi Router

Salah satu fungsi dari router adalah meneruskan paket-paket data dari satu jaringan ke jaringan lain. Agar setiap VLAN bisa melakukan komunikasi dengan VLAN lainnya dibutuhkan sebuah router untuk menghubungkannya. Konfigurasi yang dilakukan pada router adalah sebagai berikut :

* Buat Sub-interface sebanyak VLAN yg telah dibuat.
* Setting setiap gateway di setiap sub-interface.
* Setting enkapsulasi sesuai dengan enkapsulasi pada switch.
Router#configure terminal
Router(config)#interface fastethernet 0/0
Router(config-if)#no shutdown
Router(config)#interface fastethernet 0/0.10
Router(config-subif)#encapsulation dot1q 10
Router(config-subif)#ip address 192.168.1.1 255.255.255.0
Router(config)#interface fastethernet 0/0.20
Router(config-subif)#encapsulation dot1q 20
Router(config-subif)#ip address 192.168.2.1 255.255.255.0
Router(config)#interface fastethernet 0/0.30
Router(config-subif)#encapsulation dot1q 30
Router(config-subif)#ip address 192.168.3.1 255.255.255.0
Router(config)#interface fastethernet 0/0.40
Router(config-subif)#encapsulation dot1q 40
Router(config)#ip address 192.168.4.1 255.255.255.0

Protokol dot1Q digunakan untuk menghubungkan VLAN-VLAN yang ada. Penggunaan protokol tersebut karena perangkat switch berasal dari 2 vendor yang berbeda, yaitu Cisco dan Planet. Dot1Q adalah standard industri yang memungkinkan 2 buah switch yang berbeda vendor bisa melakukan trunking untuk menghubungkan VLAN.

source : http://tulisanku.com

Konfigurasi antar VLAN pada switch


Pada dasarnya, instalasi switch tidak memerlukan konfigurasi. Karena switch seyogyanya didesain memang untuk langsung dipergunakan tanpa konfigurasi awal. Namun agar dapat memaksimalkan fitur switch yang ada, kita perlu konfigurasi. Disinilah peran konfigurasi pada switch, yakni untuk management. Salah satu fitur switch yang layak untuk dikembangkan adalah VLAN. Switch yang disebutkan disini mengacu kepada Switch Cisco Catalyst 2950.
VLAN (Virtual LAN) merupakan penyempitan broadcast dari switch, dimana sekumpulan host yang tergabung dalam suatu VLAN seakan-akan memiliki LAN sendiri (Virtual LAN). Untuk dapat berkomunikasi antar VLAN diperlukan suatu router tambahan, yang disebut Router on Stick.
Biasanya konfigurasi komunikasi antar VLAN merupakan problem yang paling sering terjadi. Ada beberapa hal yang perlu diperhatikan dalam membuat VLAN dan Router on Stick. Yang pertama:
–> pada switch:
1. mode link switch-PC adalah access
switch(config-if)#switchport mode access
2. mode link switch-router adalah trunk
switch(config-if)#switchport mode trunk
3. buat VLAN
switch(vlan)#vlan name
4. masukkan port menjadi anggota VLAN
switch(config-if)#switchport access vlan
5. jikalau menggunakan 2 atau lebih switch, salah satu switch sebagai server, selebihnya adalah client.
switch(config)#vtp mode
6. buat nama domain vtp
switch(config)vtp domain
Contoh perintah ini adalah:
switch(config)#int f0/3
switch(config-­if)#switchport mode trunk
switch(config-­if)#int f0/1
switch(config-­if)#switchport mode access
switch(config-­if)#int f0/2
switch(config-­if)#switchport mode access
switch#vlan database
switch(vlan)#vlan 2 name vlan_2
switch(vlan)#vlan 3 name vlan_3
switch(vlan)#exit
switch(config)#int f0/1
switch(config-­if)#switchport access vlan 2
switch(config-­if)#int f0/2
switch(config-­if)#switchport access vlan 3
switch(config-­if)#exit
switch(config)#vtp domain telkom

–> pada router:
Buat subinterface dengan memberi ip address dan encapsulation dot1q.
router(config)#interface .
router(config-subif)#ip address
router(config-subif)#encapsulation dot1q
Contoh perintah:
router(config­if)#int f0/0.2
router(config­subif)#encapsulation dot1q 2
router(config­subif)#ip address 10.1.1.1 255.255.255.0
router(config­subif)#no shutdown
router(config­subif)#int f0/0.3
router(config­subif)#encapsulation dot1q 3
router(config­subif)#ip address 10.10.2.1 255.255.255.0
router(config­subif)#no shutdown

Untuk menguji apakah antar VLAN sudah dapat berkomunikasi atau belum, dapat menggunakan perintah ping.

semoga bermanfaat buat negriku…amin..

source : http://finag.wordpress.com

Create Dota dimesin Mikrotik


DOTA merupakan salah satu games Warcraft untuk versi online. pada gamenet games ini merupakan games terlaris selain games-games online lain seperti ragnarok, sealonline, pangya, deco dan masih banyak lagi. selain games ini gratis alias nda pake pocer, juga sangat asyik dimaenkan. disini saya coba menulis tentang bagaimana create DOTA di mesin mikrotik.

Ikuti langkah-langkah berikut :

[admin@mendem] >ip firewall nat add chain=srcnat action=masquerade out-interface=Public

[admin@mendem] >ip address add address=202.xxx.xxx.xxx/32 interface=Public (xxx diisi sesuai IP public kamu)

[admin@mendem] >ip firewall nat add chain=dstnat dst-address=202.xxx.xxx.xxx action=dst-nat to-addresses=192.168.***.*** (*** diisi sesuai dengan IP lokal yang ingin bisa create game)

[admin@mendem] >ip firewall nat add chain=srcnat src-address=192.168.***.*** action=src-nat to-addresses=202.xxx.xxx.xxx

Agar client yg tergabung dalam LAN atau yang satu network bisa bermain bersama tambahkan perintah :

[admin@mendem] >ip firewall nat add chain=dstnat dst-address=202.xxx.xxx.1-202.xxx.xxx.254 action=netmap to-addresses=192.168.***.1-192.168.***.254

[admin@mendem] >ip firewall nat add chain=srcnat src-address=192.168.***.1-192.168.***.254 action=netmap to-addresses=202.xxx.xxx.1-202.xxx.xxx.254

Sampai disini sudah berhasil , namun ternyata ada masalah yang saya hadapi, yaitu mesin mikrotik tidak dapat saya akses atau remote dari luar jaringan dan masalah lain, port SNMP ikut-ikutan ketutup sehingga untuk menampilkan traffic cacti jadi blank …ada yang bisa membantu

Fix Dota Mik

Sebelumnya saya pernah menulis tentang Rules Create Dota di Mikrotik, namun ada kendala saat rules diaktifkan maka routerbox tidak dapat di remote, diping bahkan tidak bisa menampilkan grafik MRTG/Cacti.

Setelah beberapa kali mencoba dan mencari literatur dari mbah google akhirnya ketemu rules yang cocok untuk kepentingan remote dari luar jaringan, bisa di ping dan tentunya saya bisa melihat grafik pemakaian bandwitdh lewat MRTG/Cacti.

Rules nya seperti ini :

ip firewall nat add chain=dstnat dst-address=202. x . x . x protocol=tcp dst-port=6113 action=dst-nat to-addresses=192.168. x . x to-ports=6113

ip firewall nat add chain=dstnat dst-address=202. x . x . x protocol=udp dst-port=6113 action=dst-nat to-addresses=192.168. x . x to-ports=6113

ip firewall nat add chain=srcnat src-address=192.168. x . x protocol=tcp src-port=6113 action=src-nat to-addresses=202. x . x . x to-ports=6113

ip firewall nat add chain=srcnat src-address=192.168. x . x protocol=udp src-port=6113 action=src-nat to-addresses=202. x . x . x to-ports=6113

ip firewall nat add chain=srcnat src-address=192.168. x . x -192.168. x . x action=netmap to-address=202. x . x . x -202. x . x . x to-ports=0-65535

Mungkin sudah banyak yang tahu tentang rules diatas, harapan saya rules diatas bisa dipakai siapa saja yang memerlukannya, karena dari pengalaman yang ada sungguh sulit mencari literatur atau googling tentang rules create dota di mikrotik.

semoga membantu .

taken from http://harrychanputra.wordpress.com

cara setting nat buat create dota


{
:local ipnya
:set ipnya “misal : 192.168.0″
:local iprouternya
:set iprouternya 1
:local publicnya
:set publicnya “misal : 209.182.53.161″
:local portnya
:set portnya 6201
:local startipnya
:set startipnya 2
:local endipnya
:set endipnya 53
:for i from=$startipnya to=$endipnya do={
/ip firewall nat add chain=srcnat src-address=($ipnya . “0/24″) dst-address=($ipnya . $i) protocol=tcp dst-port=($portnya) action=src-nat to-addresses=($ipnya . $iprouternya) to-ports=0-65535 comment=”$portnya”
/ip firewall nat add chain=dstnat dst-address=($publicnya) protocol=tcp dst-port=($portnya) action=dst-nat to-addresses=($ipnya . $i) to-ports=$portnya
:set portnya ($portnya + 1)}
}

setting mikrotik


FIREWALL NAT (LANGSUNG DARI RADIO)=
add chain=srcnat out-interface=[l2tp-client] src-address=[ip gateway]/[netmask] dst-address=0.0.0.0/0 action=src-nat to-addresses=[ip pub]

Maintenance Ganti Radio:
*set wlan0 periodic-calibration enable preamble-mode=short
*/ip address add address=[caller id l2tp]/[netmask] interface=wlan0
*/ip route add dst-address=10.0.0.0/8 gateway=[caller id router bts]
*/ip route add dst-address=172.16.0.0./16 gateway=[caller id router bts]
*/in l2tp-client add name=l2tp-[l2tp name] connect-to=10.1.250.2 user=[user di l2tp] password=[password di l2tp] profile=default diasble=no
*/ip address add address=[ip pub]/[netmask] interface=eth0
*/ip route pref-src=[ip pub] gateway=10.1.249.1
*/ip dns set primary-dns=202.182.48.18 secondary-dns=202.182.48.19 allow-remote-request=yes
*/ip route add dst-address=0.0.0.0./0 gateway=[local addres di l2tp] pref-src=[ip pub/ip radio]

Maintenance BTS:
*set in wi samain sama audit bts (inget /in wi set 0 name=wlan0
*/in wi set wlan0 periodic-calibration enable preamble-mode=short
*/ip address add address=[caller id bts]/[lihat di routernya] interface=wlan0
*/in ethernet set ether1 name=eth0
*/in bridge add name=br0 forward-delay=5s
*/in bridge port add interface=eth0 bridge=br0
*/in bridge port add interface=wlan0 bridge=br0
*/in wi set 0 wds-default-bridge=br0
*/ip route add dst-address=172.16.0.0/16 gateway=[ke router(vlannya bts)
*/ip route add dst-address=10.0.0.0/8 gateway=[ke router(vlannya bts)
*/system identity set name=[nama bts]
*/password

VPN RADIO:
PPP -> PPTP Server -> Enable(check) -> Default Profile = Default
IP POOL -> name=pool-1 -> addresses=[iplocal]-[iplocal](range)
PPP -> Profiles -> Default(double klik) -> local address=[ip yang di nat] -> remote address=[pool-1] -> option all= NO

/tool graphing set store-every=24hours
/ip service yg set [selain telnet disable]

bila lancard rusak???, ngecek lan card rusak??:
set eth0 auto-negotiation=no speed=10Mbps