connected to Centos openvpn but no outside internet access

Question

I am working on a query based on the following scenario. I have a node with start and end dates and I want to check either the startdate or enddate falls within the requested time range then return all properties within the nodes. For instance, startdate on a node is 08-06 and enddate is 08-09 and user params are 08-07 and 08-10, because 08-09 falls within the requested range, give me the result of the entire node. I tried some combinations and nothing worked!

// this is giving me records that will not fall under the required ranges.
WHERE
  (l.startdate>="08-07" and l.enddate<="08-10") or
  (l.startdate<="08-07" and l.enddate<="08-10")

Solution 1

Good day all,

I AM WRITING THE AS A "TUTORIAL" FOR THOSE WHO ARE SEEKING HELP WITH IPTABLES

I have been experimenting with different rules and after lots of hearaches and iptables flushes I have figured out and also got some understanding of why I had no internet access/throughput from tun0 to the eth0 interface

/etc/sysconfig/iptables

# Generated by iptables-save v1.4.7 on Thu Feb 13 17:10:07 2014

//I speak under correction but the NAT simply routes any packets BEFORE going through the firewall, so basically, since ALL the packets are going to the server - thus it needs to go through the firewall however you can tell teh server to "place" those packets onto different interfaces (eg. eth0, tun0, wlan0)

*nat

:PREROUTING ACCEPT [721:50130]

//accepts all packets from any OUTSIDE source and doesnt route to any specific interface(same as filter INPUT)

:POSTROUTING ACCEPT [0:0]

//accepts all packets from any INSIDE IP RANGE(10.8.0.0/24) source and routes it to the interface eth0 as OUTPUT(same as filter FORWARD)

:OUTPUT ACCEPT [0:0]

//accepts all packets from any INSIDE source to the OUTSIDE and doesnt route to any specific interface(same as filter OUTPUT)

-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

//append a rule to send all post-route traffic from after the firewall, from a device with a ip address in the range of 10.8.0.0/24 (including all packets since no --sport has been added) to the interface eth0 (the interface with the live internet connection for the server)

COMMIT

# Completed on Thu Feb 13 17:10:07 2014

# Generated by iptables-save v1.4.7 on Thu Feb 13 17:10:07 2014

*filter

//all the filter does is it sorts the packets into groups(based on port numbers) and allows certain packets with the suitable port numbers through, and also allows certain packets from certain ip addresses

//NOTE: the filter works with a standard policy of ACCEPT/DROP in short(the most commonly used options), packets will be dropped based on their source/where they come from BUT, just as you have rules for the NAT, so you will also have rules for the filter

:INPUT DROP [886:120871]

//All packets COMING INTO the server will be dropped/ignored

:FORWARD DROP [0:0]

//All packets needing to be forwarded between the server interfaces will be dropped/ignored

:OUTPUT ACCEPT [1209:156538]

//The server knows that it must drop all INPUT/incoming and FORWARD/transferring packets, BUT all these rules are exceptions to the policy stated, thus these exceptions will be listed below

//All packets GOING OUT from the server will be accepted/allowed

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

//Allow all packets with the following criteria: incoming from port 443(HTTPS port) on the TCP protocol

-A INPUT -i tun0 -j ACCEPT

//Allow all packets with the following criteria: incoming from interface tun0 (your VPN interface)

---

-A FORWARD -i tun0 -o eth0 -j ACCEPT

//Allow all packets with the following criteria: transfer all packets from interface tun0 to interface eth0

-A FORWARD -i eth0 -o tun0 -j ACCEPT

//Allow all packets with the following criteria: transfer all packets from interface eth0 to interface tun0

//THESE 2 RULES ARE VERY VERY IMPORTANT to allow your clients connecting to your openvpn server to have internet access, without them, you are able to connect but wont have any internet access using openvpn

-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

//Allow all packets with the following criteria: all packets related to existing connections and/or established connections between interfaces, accept them

-A INPUT -p tcp -m tcp --dport 22 -m comment --comment "SSH" -j ACCEPT

//Allow all packets with the following criteria: incoming packets on tcp port 22 and add a comment "SSH"

-A INPUT -p tcp -m tcp --dport 5252 -m comment --comment "SecureSSH" -j ACCEPT

//Allow all packets with the following criteria: incoming packets on tcp port 5252 and add a comment "SecureSSH"

-A INPUT -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

//Allow all packets with the following criteria:allow all incoming new, related or established echo/ping requests

-A OUTPUT -p icmp -m icmp --icmp-type 0 -m state --state RELATED,ESTABLISHED -j ACCEPT

//Allow all packets with the following criteria:allow all outoing new, related or established echo/ping replies

//SEE THE LINK FOR LIST OF REPLIES/REQUEST TYPES/CODES - http://www.faqs.org/docs/iptables/icmptypes.html

-A INPUT -i lo -j ACCEPT

//Allow all packets with the following criteria: incoming from localhost

COMMIT

Completed on Thu Feb 13 17:10:07 2014

I hope this helps someone, and good luck to all in the future!

Solution 2

As you don't mention it it's worth a shot ... did you enable ipv4 forwarding ?

sysctl net.ipv4.ip_forward=1

and if that works edit /etc/sysctl.conf and add or edit

# Controls IP packet forwarding
net.ipv4.ip_forward =1    

Also check that you push a suitable route from your server,

push "redirect-gateway"

or

push "redirect-gateway def1"

Comments

[Charlie Dyason]

@lain sorry, i know its worth a try, i didnt mention it but yes, I have ipforwarding enabled, yes I have push "redirect-gateway def1"

[Charlie Dyason]

good day Suranga, ty for your response, I have found the solution to the problem(which I have posted as an answer), but if i may, you are amusing that I have access to the GUI, which in this case, unfortunately i do not, but thank you in any case