Dynamic Multipoint VPN – Dual hub
March 6, 2010
In a previous article, I exposed how to setup a basic DMVPN network with one hub router in a central location and several spoke routers negotiating a dynamically built IPSec protected GRE tunnel. I also explained the central site should be secured by deploying two hub routers… Here is one solution among others using DMVPN and OSPF. (Should you need another solution you can always contact our professional services)
In this scenario, the spoke routers will have two GRE tunnels, one ending on each hub routers.
First we configure the hub routers with mGRE interfaces and OSPF.
The tunnel interfaces use point-to-point OSPF network type by default, we will need to reconfigure them with NBMA OSPF network type as we will have several spoke routers ending their tunnel on them. We will also set the OSPF costs in order to have R0 acting as the preferred hub router and R1 as the backup hub router.
Hub router R0′s config
interface Tunnel0 ip address 10.0.0.1 255.255.255.0 no ip redirects ip nhrp network-id 1 ip ospf network non-broadcast ip ospf cost 10 tunnel source FastEthernet2/1 tunnel mode gre multipoint tunnel key 1 ! interface FastEthernet2/0 ip address 10.10.10.1 255.255.255.0 ! interface FastEthernet2/1 ip address 10.4.0.1 255.255.255.0 ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.0.0.255 area 10 network 10.10.10.0 0.0.0.255 area 10 ! ip route 0.0.0.0 0.0.0.0 10.4.0.2
Hub router R0′s config
interface Tunnel1 ip address 10.1.1.1 255.255.255.0 no ip redirects ip nhrp network-id 1 ip ospf network non-broadcast ip ospf cost 100 tunnel source FastEthernet2/1 tunnel mode gre multipoint tunnel key 1 ! interface FastEthernet2/0 ip address 10.10.10.2 255.255.255.0 ! interface FastEthernet2/1 ip address 10.4.1.1 255.255.255.0 ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.0.0.255 area 10 network 10.10.10.0 0.0.0.255 area 10 ! ip route 0.0.0.0 0.0.0.0 10.4.1.2
Then we can start to add spoke routers. The spoke routers will use point-to-point GRE (as we don’t want spoke-to-spoke direct communication) with NBMA OSPF network type in order to be compatible with the hub routers’ settings. We also need to define the neighbors as we’re on an NBMA network. I’ve chosen to do that on the spoke routers as ì don’t want to have to touch the hub routers config when new spoke routers are added.
Spoke router R2′s config
interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Tunnel0 ip address 10.0.0.2 255.255.255.0 ip nhrp map 10.0.0.1 10.4.0.1 ip nhrp network-id 1 ip nhrp nhs 10.0.0.1 ip ospf network non-broadcast ip ospf cost 10 ip ospf priority 0 tunnel source FastEthernet1/0 tunnel destination 10.4.0.1 tunnel key 1 ! interface Tunnel1 ip address 10.1.1.2 255.255.255.0 ip nhrp map 10.1.1.1 10.4.1.1 ip nhrp network-id 1 ip nhrp nhs 10.1.1.1 ip ospf network non-broadcast ip ospf cost 100 ip ospf priority 0 tunnel source FastEthernet1/0 tunnel destination 10.4.1.1 tunnel key 1 ! interface FastEthernet1/0 ip address 10.4.2.1 255.255.255.0 ! router ospf 1 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 10 network 10.0.0.0 0.0.0.255 area 10 network 10.1.1.0 0.0.0.255 area 10 neighbor 10.0.0.1 neighbor 10.1.1.1 ! ip route 0.0.0.0 0.0.0.0 10.4.2.2
Same config is applied on spoke router R3, only the IP change.
To check the GRE tunnels are operational, we only have to ping the tunnels’ internal IP from one router to the others three.
From spoke router R2 :
R2#ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms R2#ping 10.1.1.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/24 ms R2#ping 10.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/24 ms R2#ping 10.0.0.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/32 ms
If we check the NHRP entries on the hubs R0 or R1, we can see the two entries have been learned dynamically and the public IP used by the remote routers.
R1#sh ip nhrp 10.1.1.2/32 via 10.1.1.2, Tunnel1 created 02:08:37, expire 01:38:57 Type: dynamic, Flags: authoritative unique registered used NBMA address: 10.4.2.1 10.1.1.3/32 via 10.1.1.3, Tunnel1 created 02:08:36, expire 01:38:57 Type: dynamic, Flags: authoritative unique registered used NBMA address: 10.4.3.1
R0#sh ip nhrp 10.0.0.2/32 via 10.0.0.2, Tunnel0 created 02:15:15, expire 01:53:44 Type: dynamic, Flags: authoritative unique registered NBMA address: 10.4.2.1 10.0.0.3/32 via 10.0.0.3, Tunnel0 created 02:11:04, expire 01:53:44 Type: dynamic, Flags: authoritative unique registered NBMA address: 10.4.3.1
Now, check OSPF is doing what we want. First we check the ospf neighbors on spoke router R2
R2#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.10.10.2 1 FULL/DR 00:01:54 10.1.1.1 Tunnel1 10.10.10.1 1 FULL/DR 00:01:55 10.0.0.1 Tunnel0
Then we can check corporate subnet 10.10.10.0/24 and other spokes (here R3′s Loopback 3.3.3.3) are reachable via the primary hub router R0.
R2#sh ip route ospf
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/11] via 10.0.0.3, 00:42:46, Tunnel0
10.0.0.0/24 is subnetted, 4 subnets
O 10.10.10.0 [110/11] via 10.0.0.1, 00:42:46, Tunnel0
On the hub routers we can check the spoke routers are always reached via R0.
R0#sh ip route ospf
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/11] via 10.0.0.2, 00:49:41, Tunnel0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/11] via 10.0.0.3, 00:49:41, Tunnel0
10.0.0.0/24 is subnetted, 4 subnets
O 10.1.1.0 [110/101] via 10.10.10.2, 00:49:41, FastEthernet2/0
R1#sh ip route ospf
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/12] via 10.10.10.1, 00:50:52, FastEthernet2/0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/12] via 10.10.10.1, 00:50:52, FastEthernet2/0
10.0.0.0/24 is subnetted, 4 subnets
O 10.0.0.0 [110/11] via 10.10.10.1, 00:50:52, FastEthernet2/0
Now that we have IP connectivity, we can enable IPSec exactly as we did last time.
crypto isakmp policy 10 authentication pre-share crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set mySet esp-aes esp-sha-hmac ! crypto ipsec profile myDMVPN set security-association lifetime seconds 120 set transform-set mySet set pfs group2 interface Tunnel0 tunnel protection ipsec profile myDMVPN interface Tunnel1 tunnel protection ipsec profile myDMVPN
That’s all folks! Now we have a DMVPN setup with redundant hub routers…
ClamXav differential update
November 29, 2009
ClamXav is a free virus checker for Mac OS X. It uses the tried, tested and very popular ClamAV open source antivirus engine as a back end.
The default install of ClamXav does not enable the automatic virus definition update. When a user enables those automatic updates, a ‘good old cron job’ is created for that user. Three minor concerns with that method are:
- Each users on the system can enable the automatic updates leading to multiple redundant checks for new virus definitions
- The users do not have write access to ClamXav directories and are not able to create a temporary directory required for differential updates. Fortunately ClamXav fall back to a standard update where the entire virus definition file is downloaded.
- All the users who enable the automatic updates will get e-mails containing an error message like this one :
clamxav ERROR: chdir_tmp: Can't create directory ./clamav-97e66bd7fbb
Only the _clamav user has write access to his directories. I’ve found several workarounds for this by googling but most of them were either not secure like setting the _clamav user’s directories world wide writable, either not elegant like putting the cron job in the root’s crontab…
The only elegant workaround I’ve found so far is still requiring some manual configuration but at least it uses Apple’s vision of daemon and recurrent tasks; it uses launchd. I won’t explain launchd here but Apple website or AFP548 website are very good start to understand its philosophy.
We will configure a launchd daemon to start the virus definition update every day at 21:30 as _clamav user. Launchd is configured via property list files (.plist) placed in appropriate directories. In this case we want the daemon to be started as long as the system is started (i.e. regardless if a user is logged or not). We will place our plist file in /Library/LaunchDaemons/.
1. <?xml version="1.0" encoding="UTF-8"?> 2. <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> 3. <plist version="1.0"> 4. <dict> 5. <key>Label</key> 6. <string>com.clamxav.freshclam</string> 7. <key>UserName</key> 8. <string>_clamav</string> 9. <key>LowPriorityIO</key> 10. <true/> 11. <key>Nice</key> 12. <integer>1</integer> 13. <key>Program</key> 14. <string>/usr/local/clamXav/bin/freshclam</string> 15. <key>ProgramArguments</key> 16. <array> 17. <string>/usr/local/clamXav/bin/freshclam</string> 18. <string>--quiet</string> 19. <string>--log=/usr/local/clamXav/share/clamav/freshclam.log</string> 20. </array> 21. <key>StartCalendarInterval</key> 22. <dict> 23. <key>Hour</key> 24. <integer>21</integer> 25. <key>Minute</key> 26. <integer>30</integer> 27. </dict> 28. </dict> 29. </plist>
Lines 5-6 : define the daemon’s name
Lines 7-8 : define the user the daemon will run as
Lines 9-12 : reduce the update process priority as it is not required to run fast
Lines 13-20 : define the daemon’s executable and its parameters
Lines 21- 27 : schedule when the daemon must run
That plist file must be placed in /Library/LaunchDaemons/. It will be automatically loaded after each reboot but you can manually load it with launchctl if you don’t want to restart your computer.
$ sudo launchctl load /Library/LaunchDaemons/com.clamxav.freshclam.plist $ sudo launchctl list | grep com.clamxav.freshclam - 0 com.clamxav.freshclam
Now you can check in the log file (/usr/local/clamXav/share/clamav/freshclam.log) the error message has disappeared and differential update is now working fine…
ClamAV update process started at Sat Nov 28 21:30:09 2009 main.cvd is up to date (version: 51, sigs: 545035, f-level: 42, builder: sven) Downloading daily-10091.cdiff [100%] daily.cld updated (version: 10091, sigs: 115838, f-level: 44, builder: ccordes) Database updated (660873 signatures) from database.clamav.net (IP: 193.1.193.64) Clamd successfully notified about the update.
Thanks for leaving a comment if you found this useful
Dynamic Multipoint VPN
September 22, 2009
Ever wonder how to provision several hundreds of VPNs from remote offices with dynamic IP to a central site with minimal configuration? Cisco offer an elegant solution called Dynamic Multipoint VPN. With DMVPN the central site does not need to know the remote site IP in advance, it will learn it via NHRP protocol when the remote router will come up.
First we will create IP connectivity via GRE tunnels and NHRP then we will secure the GRE tunnels with IPSec.
The hub router will use a multipoint GRE interface for ease of management. That way we do not need to provision a new tunnel interface per remote office. In fact, the central router will not need to be reconfigured at all for any additional remote site.
Hub router R1:
interface Tunnel0
ip address 10.10.10.1 255.255.255.0
ip nhrp network-id 1
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
interface Fa0/0
ip address 1.1.1.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 1.1.1.1
Spoke routers (R2 and R3 in this example) will use point-to-point GRE tunnel pointing to central site’s hub router R1. NHRP will be configured to use R1 as next-hop server. With this setup, spoke-to-spoke traffic will flow through the hub making the hub a central point where you can enforce security…
Spoke router R2:
interface Tunnel0
ip address 10.10.10.2 255.255.255.0
ip nhrp map 10.10.10.1 1.1.1.2
ip nhrp network-id 1
ip nhrp nhs 10.10.10.1
tunnel source FastEthernet0/0
tunnel destination 1.1.1.2
tunnel key 1
interface Fa0/0
ip address 2.2.2.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 2.2.2.1
Spoke router R3
interface Tunnel0
ip address 10.10.10.3 255.255.255.0
ip nhrp map 10.10.10.1 1.1.1.2
ip nhrp network-id 1
ip nhrp nhs 10.10.10.1
tunnel source FastEthernet0/0
tunnel destination 1.1.1.2
tunnel key 1
interface Fa0/0
ip address 3.3.3.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 3.3.3.1
At this stage, if the router can communicate with each others via their Fa0/0 interface then the GRE tunnels are usable. In this example, “Internet” router is directly connected to all the routers and the routers R1, R2 and R3 simply have a default route pointing to the “Internet” router.
To check the GRE tunnels are operational, we only have to ping the tunnels’ internal IP from one router to the others two.
R2#ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 272/313/420 ms
R2#ping 10.10.10.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 312/564/876 ms
If we check the NHRP entries on the hub R1, we can see the two entries have been learned dynamically and the public IP used by the remote routers.
R1#sh ip nhrp
10.10.10.2/32 via 10.10.10.2, Tunnel0 created 00:11:31, expire 01:48:28
Type: dynamic, Flags: authoritative unique registered used
NBMA address: 2.2.2.2
10.10.10.3/32 via 10.10.10.3, Tunnel0 created 00:08:19, expire 01:51:52
Type: dynamic, Flags: authoritative unique registered used
NBMA address: 3.3.3.2
Same info without the timers…
R1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
10.10.10.2/32 10.10.10.2 2.2.2.2 dynamic Tu0 < >
10.10.10.3/32 10.10.10.3 3.3.3.2 dynamic Tu0 < >
Statistics about the NHRP protocol itself
R1#sh ip nhrp traffic
Tunnel0
Sent: Total 3
0 Resolution Request 0 Resolution Reply 0 Registration Request
3 Registration Reply 0 Purge Request 0 Purge Reply
0 Error Indication
Rcvd: Total 3
0 Resolution Request 0 Resolution Reply 3 Registration Request
0 Registration Reply 0 Purge Request 0 Purge Reply
0 Error Indication
R1#sh ip nhrp summary
IP NHRP cache 2 entries, 496 bytes
0 static 2 dynamic 0 incomplete
On the spoke routers we can check the same… Here we can see the NHRP entry is statically defined
R3#sh ip nhrp
10.10.10.1/32 via 10.10.10.1, Tunnel0 created 00:13:31, never expire
Type: static, Flags: authoritative
NBMA address: 1.1.1.2
R3#sh ip nhrp summary
IP NHRP cache 1 entry, 248 bytes
1 static 0 dynamic 0 incomplete
And we can check the NHRP’s next-hop server used.
R3#sh ip nhrp nhs
Legend:
E=Expecting replies
R=Responding
Tunnel0:
10.10.10.1 RE
Should you want to allow spoke-to-spoke tunnels to be built dynamically, you only need to replace the tunnel destination 1.1.1.2 command on the spokes by tunnel mode gre multipoint making the spokes’ tunnel interface an mGRE interface. For the remaining of this article, we won’t use mGRE interfaces on the spokes.
Now that we have IP connectivity, we still have to secure those dynamically created GRE tunnels with IPSec. Here for simplicity we will use pre-shared key as authentication method which is not recommended for production deployment…
On the hub and spoke routers, just configure ISAKMP/IPSec parameters and enable IPSec on the tunnel insterfaces.
crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set mySet esp-aes esp-sha-hmac
!
crypto ipsec profile myDMVPN
set security-association lifetime seconds 120
set transform-set mySet
set pfs group2
interface Tunnel0
tunnel protection ipsec profile myDMVPN
Check IPSec SA are well negotiated
R1#sh crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 1.1.1.2
protected vrf: (none)
local ident (addr/mask/prot/port): (1.1.1.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
current_peer 2.2.2.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 121, #pkts encrypt: 121, #pkts digest: 121
#pkts decaps: 121, #pkts decrypt: 121, #pkts verify: 121
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 1.1.1.2, remote crypto endpt.: 2.2.2.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xA2BC2FED(2730242029)
inbound esp sas:
spi: 0x2884EDEA(679800298)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2005, flow_id: SW:5, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4463708/83)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xA2BC2FED(2730242029)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2004, flow_id: SW:4, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4463708/82)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
That’s it! The DMVPN setup is ready for wide deployment… Of course central hub router should be duplicated for redundancy, it will exposed in a future post.
Thanks for leaving a comment if you found this useful
IPv6 Firewall with Linux
September 17, 2009
More and more server hoster have configured IPv6 on their network. And most of their Linux based servers come with a basic IPv6 configuration. Even if IPv6 is not used, it is there and widely open as the netfilter/iptables default policy is ACCEPT.
If you don’t use IPv6 at all, disable it. On Debian, the interfaces configuration is located in /etc/network/interfaces. Remove all the inet6 configuration looking like this :
iface eth0 inet6 static address 2001:db8:4:fe34::3ea1 netmask 64
If you plan to use IPv6, first you have to know ICMPv6 should be filtered carefully. In IPv6, ICMPv6 is widely used. It replaces IPv4′s ARP with neighbour-solicitation and neighbour-advertisement ICMPv6 messages. It is used for router discovery via router-solicitation and router-advertisement ICMPv6 messages. It replaces IPv4′s IGMP with group-membership-query, group-membership-report and group-membership-reduction ICMPv6 messages.
Here is a small script to activate IPv6 filtering with netfilter/ip6tables. The script has been test on Debian but it should work on other Linux flavor.
#!/bin/sh -e
#
# Simple example IPv6 Firewall configuration.
#
# Caveats:
# - This configuration applies to all network interfaces
# if you want to restrict this to only a given interface use
# '-i INTERFACE' in the ip6tables calls.
# - Remote access for TCP/UDP services is granted to any host,
# you probably will want to restrict this using '--source'.
#
# description: Activates/Deactivates the firewall at boot time
#
# You should test this script before applying with safe-restart option
#
IP6TABLES=/sbin/ip6tables
#IP6TABLES="/sbin/ip6tables -i eth0"
[ -x "$IP6TABLES" ] || exit 1
# Inbound TCP ports
TCP_INPUT_PORTS="21 22 53 443"
# Inbound UDP ports
UDP_INPUT_PORTS="53"
# Allowed ICMP messages
ALLOWED_ICMP="\
packet-too-big \
destination-unreachable \
time-exceeded parameter-problem \
echo-request \
echo-reply \
router-advertisement \
neighbour-solicitation \
neighbour-advertisement"
fw_start () {
# Allow related and established connection.
$IP6TABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allow ICMP as defined in ALLOWED_ICMP
if [ -n "$ALLOWED_ICMP" ] ; then
for ICMP_TYPE in $ALLOWED_ICMP; do
$IP6TABLES -A INPUT -p icmpv6 --icmpv6-type ${ICMP_TYPE} -j ACCEPT
done
fi
# Open allowed TCP ports if any
if [ -n "$TCP_INPUT_PORTS" ] ; then
for PORT in $TCP_INPUT_PORTS; do
$IP6TABLES -A INPUT -m state --state NEW -p tcp --dport ${PORT} \
-j ACCEPT
done
fi
# Open allowed UDP ports if any
if [ -n "$UDP_INPUT_PORTS" ] ; then
for PORT in $UDP_INPUT_PORTS; do
$IP6TABLES -A INPUT -m state --state NEW -p udp --dport ${PORT} \
-j ACCEPT
done
fi
# Allow traffic to the loopback (needed by some applications)
$IP6TABLES -A INPUT -i lo -j ACCEPT
# Log and drop all other packets.
$IP6TABLES -A INPUT -j LOG
$IP6TABLES -P INPUT DROP
# Los and drop all packet to be forwarded, we're not a router...
$IP6TABLES -A FORWARD -j LOG
$IP6TABLES -P FORWARD DROP
# We're not going to filter outgoing packets
# but you can if you're paranoid like I am...
$IP6TABLES -P OUTPUT ACCEPT
}
# fw_stop disables completely the firewall and reset all chains to
# the default policy ACCEPT
fw_stop () {
$IP6TABLES -P INPUT ACCEPT
$IP6TABLES -P FORWARD ACCEPT
$IP6TABLES -P OUTPUT ACCEPT
$IP6TABLES -t mangle -P PREROUTING ACCEPT
$IP6TABLES -t mangle -P POSTROUTING ACCEPT
$IP6TABLES -t mangle -P INPUT ACCEPT
$IP6TABLES -t mangle -P OUTPUT ACCEPT
$IP6TABLES -t mangle -P FORWARD ACCEPT
$IP6TABLES -t mangle -F
$IP6TABLES -t mangle -X
$IP6TABLES -F
$IP6TABLES -X
}
# fw_clear remove the rule set from the firewall and keep the
# current default policy
fw_clear () {
$IP6TABLES -t mangle -F
$IP6TABLES -t mangle -X
$IP6TABLES -F
$IP6TABLES -X
}
case "$1" in
start|restart)
echo -n "Starting IPv6 firewall.."
fw_clear
fw_start
echo "done."
;;
stop)
echo -n "Stopping IPv6 firewall.."
fw_stop
echo "done."
;;
clear)
echo -n "Clearing IPv6 firewall rules.."
fw_clear
echo "done."
;;
test|safe-restart)
echo -n "Safely restarting IPv6 firewall..."
fw_clear
fw_start
test=""; read -t 10 -p "Is it still OK? " test ; \
[ -z "$test" ] && fw_stop
echo "done."
;;
*)
echo "Usage: $0 {start|stop|restart|safe-restart|clear}"
exit 1
;;
esac
exit 0
Now let’s make the ip6firewall to start at boot time :
update-rc.d ip6firewall start 41 S . stop 34 0 6 .
Now the server is only accepting packets on ports we have decided.
By the way, I’ve been certified ipv6 Guru by Hurricane Electric… 
That’s all folks!
Thanks for leaving a comment if you found this useful
J-Partner Consultant
April 24, 2009
exp-NETWORKS is proud to announce it became J-Partner Consultant. This partnership with Juniper is a guarantee you can count on exp-Networks expertise on Juniper products.
Here is what Juniper says about J-Partner Consultant:
Consultants play a critical role understanding, deploying, and provisioning high-performance networks. Juniper Networks recognizes this and is responding to the consultant sector by providing critical information on Juniper’s technology, products, services, and solutions specifically tailored to the independent role that consultants play.
Juniper Networks J-partner program for Consultants enables authorized consultants to gain timely access to key data on Juniper’s enterprise and service provider solutions; some of this information is available exclusively to Juniper Networks Consultant partners. In addition, Juniper may also selectively invite authorized consultants to participate in enhanced activities such as certification training, conferences, or technology and business innovation opportunities.
Consultants are a part of a diverse, global community of individuals or organizations who provide professional advice, services, guidance, or knowledge-based input. Consultants span global and regional enterprise, service provider, and public sector market opportunities. Consultants are Not product resellers, dedicated managed service partners, analysts, or members of the press. as with all J-partner relationships, Juniper reserves the right to deny entry or remove a partner from the program.
Cisco certified
April 24, 2009
All our consultants are Cisco certified.
Here what Cisco says about certifications:
Cisco Certified Network Professional validates knowledge and skills required to install, configure and troubleshoot converged local and wide area networks. With a Cisco certification, a network professional demonstrates the knowledge and skills required to manage the routers and switches that form the network core, as well as edge applications that integrate voice, wireless, and security into the network.
Recent Comments