Komunitas Indonesia Open Source

duh!

Akhirnya pppoeconf sudah berhasil, ternyata itu setelah aku install ubuntu yg baru. sepertinya ubuntu yg lama ada yg tdk support atau yg tdk dpahami.

nah, masalah berikutnya, setelah pppoeconf berhasil, saya tdk bisa tahu gimana mau konek ke internet. soalnya pas aku ping ke google.com gak mau

apakah ada masaalh di gateway?

wah, moga ada yg bisa membantu

Finally. Koneksi sudah dpt. IP Public sudah ketemu. dan VPN sudah diinstall dengan OpenVPN
time to move again

(kok jadi diary ya?)

kira kira seperti inilah wujudnya

http://www.taiter.com/blog/2009/04/open … ing-f.html

aku sekian lama googling, aku menemukan yang ini, dan sepertinya memang ini yg aku butuhkan. semoga benar benar ini dia solusinya.

terima kasih


OpenVPN: Firewall and Routing for Tunnel Connections
By
Tait Clarridge
on April 22, 2009 9:18 AM | Permalink | Comments (0) | TrackBacks (0)
I recently started working with OpenVPN to replace a costly and incompatible VPN system we had in the office.

During my configuration I noticed that there was a lot of firewalling and routing to be done and so now I will share my findings and configurations with you.

The best part of OpenVPN is that it is very easy to set up for a simple connection at home. Basically fire up the server with the defaults, open the port on your home router and you have yourself a secure connection to your home network. All of the defaults and setup can be found in the OpenVPN How-TO.
So, where to start. I might as well explain exactly what I tried to accomplish and the goals of "upgrading" to OpenVPN.

The biggest problem we were having was the compatibility with different operating systems and the Checkpoint VPN client. I am basically the only guy who tries to use Linux primarily in a Windows based environment so I eventually figured out how to patch Openswan 2.6.18 to connect to the Checkpoint server. This is a whole other story, but basically I had to look at the patches for Openswan 2.4.x that someone had written then port them to work with the new version. This took a VERY long time because they reorganized a lot of code into different files and in the end it still didn't work until I forced Openswan to go into "Checkpoint SecureClient Mode" ALL the time. So it wasn't a great solution, but it worked... kind of. Other members of our tech staff have Vista Business 64-bit, and surprise surprise... Checkpoint has no 64 bit client support.

After realizing that we were spending a ton of money on an incompatible and slow system, I decided to look into OpenVPN. The setup was very simple; our servers are CentOS so we just had to add the rpmforge repo and grab the package through yum. And as long as you stick to the setup steps in the HOW-TO, you will be fine.

OpenVPN is great because there is compatibility for Linux (NetworkManager has a freakin' plugin for OpenVPN), Windows (64-bit and Vista), and Mac OS X. This was a major selling point, not only for me but those users who have had to delay upgrading or reinstalling due to incompatibility with Checkpoint clients.

Alright, enough babbling from me about how great OpenVPN is... I swear I don't work for them.

I am not going to outline the install process as I basically followed the HOW-TO word for word in setting up the server certificates, CA certificate, DH parameters, and client certificates.

I initially configured the server to listen for internal connections so I could test. I suggest this as a first step so you know that it actually connects! Basically flush the firewall rules and try to ping the VPN address that the server takes, in the default options used in the HOW-TO, you should be able to ping 10.8.0.1 while connected to the VPN.

There are a few things that I will go over that might make your life easier while troubleshooting, the first is getting your VPN clients to be able to connect to the internal network and not just ping able to ping the tunnel device on the VPN server.

For my setup, we wanted to have two interfaces; one internal that could connect to the internal office network (duh..), and one external that would be used only for VPN and SSH.

I will make everything here look like the defaults in the HOW-TO incase some of you are googling for those answers and have landed here. In which case, please read on!

Firewall Setup

Since I wanted to have two interfaces, with only one of them with an IP accessible from the internet, I scrubbed the original firewall config that was default in CentOS.

We might as well setup our own firewall so we know exactly what it is doing. I have created a script (if you leave a comment or shoot me an email, I can send it to you) but I will just deconstruct it here for your benefit.

This whole entry assumes that your VPN server is a fresh install and dedicated to becoming an OpenVPN server with nothing else on it. It also assumes that OpenVPN has already been configured and the service is started, and that you are using a tunnel and not bridging.

First, let's scrub all firewall rules, tables, and delete any user defined (or RH defined chains).

iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

Next, make sure that IPv4 forwarding is enabled.

cat /proc/sys/net/ipv4/ip_forward

If the above shows a "1", forwarding is enabled; if it does not, run the command below.

echo "1" > /proc/sys/net/ipv4/ip_forward

Now you are ready to configure the firewall. I set the default policy of the INPUT chain to DROP because it is easier to manage when all you have to do is add access to the ports and interfaces you want to have access.

iptables -P INPUT DROP

Next, you can make the loopback device and internal interface trusted by iptables. My internal interface is eth0.

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT

Now you can make the tunnel interface trusted. If you did not specify one, you can issue a sort of wildcard to allow all tunnel devices to be trusted.

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT

The next part assumes that you have eth1 as the external, internet facing interface.
We are now going to create the rule allowing both SSH and OpenVPN to be available from the internet. NOTE: You might want to change the default port of SSH to something else, in which case you can just change the "22" in the command below to whatever you allocate as the new port. This also assumes that you are using UDP port 1194 for OpenVPN (the default).

iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --dport 1194 -j ACCEPT

Next we can create a NAT rule to allow the VPN clients to be Masqueraded so they can connect to resources on your office network. I am using the defaults for a non-bridging setup here again as well as using eth0 as the internal interface. This should be on one line.

iptables -t nat -A POSTROUTING -s 10.8.0.0/255.255.255.0 -o eth0 -j MASQUERADE

That should take care of the firewalling. Next we will setup the routing.

Routing

This port is very important. Since I am kind of a networking noob, I assumed that any packets that found their way to the server using an external interface would go out that SAME external interface. But I learned that they will follow the default route. So basically if your server is setup with the default route pointing to the gateway on its internal interface, you can skip these next lines.

This part can be skipped if you have a connection to the internal network as your default route. Otherwise, if you are using the external connection as your default route, we need to change that.

First you need to print your routing table on the server:

route -n

This should show the VPN connection routing near the top (all the stuff with 10.8.0.1 etc.) and your default route should be at the bottom. This part I had completely forgotten about once I brought up my external interface, then realized that it was necessary in accessing the internal network.

So for example, if my external interface gateway is 200.55.22.1 and my internal interface gateway is 192.168.10.1 then we can issue the following commands to make the internal gateway the default.

route del default 200.55.22.1 netmask 0.0.0.0 dev eth1
route add default gw 192.168.10.1 dev eth0

Now you should be able to ping any resources on your office network; like file servers, mail servers, etc..

Next we have to make a new routing table, and a rule for routing marked packets through that new routing table.

This next part has been slightly changed from the author's default so it will work with what I needed. The original can be found here http://troykelly.com/2009/04/04/sending … nterface/.

What we will do, in order, is:


    * Flush the routing table 200
          o The 200 table is an arbitrary number, just something that we hope isn't in use!
    * Cleanup any stale fwmark rules
          o This ensures that you don't have two rules for the same packet marking
    * Mark SSH and VPN packets using iptables
    * Add the external route as default to table 200
          o Remember that I will be using the same external gateway IP as used above
    * Add the fwmark rule
          o Basically says "IF packet marked as x, use table 200"


Here are the commands.

ip route flush table 200
ip rule del fwmark 0x50
iptables -t mangle -A OUTPUT -j MARK --set-mark 80 -p udp --sport 1194
iptables -t mangle -A OUTPUT -j MARK --set-mark 80 -p tcp --sport 22
ip route add table 200 default via 200.55.22.1
ip rule add fwmark 0x50 table 200

If you are unsure, the 0x50 part is just the hex value for 80 that iptables marks the packet with.

Now you should be done with the firewall and routing. The packets that come in from the external interface that are ssh and vpn (the only ports opened in iptables), they will be marked and sent back out the external interface.

If you have any questions, please let me know. Leave a comment if this helps of if I have been too confusing.

wow... keknya forum ini udah mati