Page 1 of 1

NAT problem in iptables

Posted: 2019/05/31 11:54:37
by nike
Sir
centos 7 running web application and vpn server with public ip ..so i configured it using iptables . everything running fine ....
but there is problem when i use NAT postrouting for vpn user .....NAT is not working ....here my iptables setting below...help plz




# INPUT iptables Rules
# Accept loopback input
iptables -A INPUT -i lo -p all -j ACCEPT

# allow 3 way handshake
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

### DROPspoofing packets
iptables -A INPUT -s 10.0.0.0/8 -j DROP
iptables -A INPUT -s 169.254.0.0/16 -j DROP
#iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 127.0.0.0/8 -j DROP
#iptables -A INPUT -s 192.168.0.0/24 -j DROP

iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -d 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP
iptables -A INPUT -d 240.0.0.0/5 -j DROP
iptables -A INPUT -s 0.0.0.0/8 -j DROP
iptables -A INPUT -d 0.0.0.0/8 -j DROP
iptables -A INPUT -d 239.255.255.0/24 -j DROP
iptables -A INPUT -d 255.255.255.255 -j DROP

#for SMURF attack protection
iptables -A INPUT -p icmp -m icmp --icmp-type address-mask-request -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/second -j ACCEPT

# Droping all invalid packets
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP

# flooding of RST packets, smurf attack Rejection
iptables -A INPUT -p tcp -m tcp --tcp-flags RST RST -m limit --limit 2/second --limit-burst 2 -j ACCEPT

# Protecting portscans
# Attacking IP will be locked for 24 hours (3600 x 24 = 86400 Seconds)
iptables -A INPUT -m recent --name portscan --rcheck --seconds 86400 -j DROP
iptables -A FORWARD -m recent --name portscan --rcheck --seconds 86400 -j DROP

# Remove attacking IP after 24 hours
iptables -A INPUT -m recent --name portscan --remove
iptables -A FORWARD -m recent --name portscan --remove

# These rules add scanners to the portscan list, and log the attempt.
iptables -A INPUT -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "portscan:"
iptables -A INPUT -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "portscan:"
iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

# Allow the following ports through from outside
iptables -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

# Allow ping means ICMP port is open (If you do not want ping replace ACCEPT with REJECT)
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# Lastly reject All INPUT traffic
iptables -A INPUT -j REJECT


################# Below are for OUTPUT iptables rules #############################################

## Allow loopback OUTPUT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow the following ports through from outside
# SMTP = 25
# DNS =53
# HTTP = 80
# HTTPS = 443
# SSH = 22
# vpn=1194
### You can also add or remove port no. as per your requirement

iptables -A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 1194 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT

# Allow pings
iptables -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# Lastly Reject all Output traffic
iptables -A OUTPUT -j REJECT

## Reject Forwarding traffic
iptables -A FORWARD -j REJECT

########################### Below for NAT Routing###########################

##Accept for Postrouting traffic
iptables -t nat -A POSTROUTING -s X.X.X.X/24 -o enp0s3 -j MASQUERADE

Re: NAT problem in iptables

Posted: 2019/05/31 16:56:29
by aks
What kind of VPN (IPSec - which one, OpenVPN, L2TP with or without TLS etc)?
What kind of client (Windows/Linux/UNIX etc)?
iptables -t nat -A POSTROUTING -s X.X.X.X/24 -o enp0s3 -j MASQUERADE
Otherwise I would have throught the interface to use would have been a tun interface (or maybe that's just "old" thinking).

Re: NAT problem in iptables

Posted: 2019/06/01 05:55:07
by nike
aks wrote:
2019/05/31 16:56:29
What kind of VPN (IPSec - which one, OpenVPN, L2TP with or without TLS etc)?
What kind of client (Windows/Linux/UNIX etc)?
iptables -t nat -A POSTROUTING -s X.X.X.X/24 -o enp0s3 -j MASQUERADE
Otherwise I would have throught the interface to use would have been a tun interface (or maybe that's just "old" thinking).

sir
Thanks for reply.
If i configure only NAT it is working but when i use all protection like above in my iptables NAT not work....this is problem ..

i use openvpn with TLs support using tun interface and all type of client i.e. andriod, windows & ubuntu..
is it necessary about client type in iptables ?

Re: NAT problem in iptables

Posted: 2019/06/02 16:44:59
by aks
i use openvpn
Normally openvpn makes a "pseudo" TUNx device.
If you tell a computer do so something (as in send this tho this particular interface, then it will). Usually that's not what you want. Usually you want the "extra" bits (like NAT). TLS does makes it harder, but you're going with OpenVPN which is itself it own thing (it's not really standardised, some parts are open source, that is all).
is it necessary about client type in iptables ?
Is state necessary in network filtering? Answer: 100% yes. Does it matter if my client is using <this protocol> or <that protocol>? Uh, yes!

Start thinking about what is going where. What are the routing rule tables happening at both ends? That's the start (at least).

Re: NAT problem in iptables

Posted: 2019/06/04 06:17:24
by jlehtone
nike wrote:
2019/06/01 05:55:07
NAT not work
What does that mean?

You have a server with one physical interface (to public subnet)?

DNS, SSH, HTTP/HTTPS, and openvpn clients can access the server.

When there is vpn connection(s), the server has interfaces to more than on subnet. Should the server route between those subnets?

How did you choose the current filter rules?

Re: NAT problem in iptables

Posted: 2019/06/04 16:23:49
by TrevorH
As was posted before, if you use iptables -t nat -A POSTROUTING -s X.X.X.X/24 -o enp0s3 -j MASQUERADE and expect that to work for the VPN then it will not as it only affects traffic going via enp0s3. Most likely you need to point it to the interface that the vpn is using - usually called something like ppp0 or tun0.

Re: NAT problem in iptables

Posted: 2019/06/05 09:07:33
by jlehtone
aks wrote:
2019/06/02 16:44:59
Start thinking about what is going where.
That is indeed crucial.

Note: Openvpn can route (tun) or bridge (tap).

I have an openvpn client. The machine has address ipA on interface eth0.

When openvpn is in use, the machine has also address ipB on interface tun0.
There is machine ipbX on the other end of the tunnel. If I ping ipbX,
1. the ping is routed out from tun0. Sender is ipB.
2. openvpn sends an encrypted packet that is routed out from eth0. Sender is ipA
3. encrypted reply arrives to ipA for openvpn
4. pong arrives from tun0 to ipB.

The INPUT and OUTPUT chains saw both the ping-pong between ipB and ipbX, and the openvpn traffic between ipA and the openvpn server. Nothing hits FORWARD and nothing requires NAT.

Lets call the openvpn "server" ipaY. There is third machine ipaZ reachable from ipA.

New connection:
1. encrypted reply arrives to ipA from ipaY
2. INPUT considers (from=ipaY, to=ipA/openvpn)
3. packet from ipbX arrives from tun0 and has destination ipaZ
4. routing decides that packet should go out from eth0
5. FORWARD chain considers (from=ipbX, to=ipaZ)
6. POSTROUTING replaces the 'from' of packet
7. Packet (from=ipA, to=ipaZ) leaves from eth0

Reply:
1. reply packet arrives to ipA from ipaZ via eth0
2. nat table remembers and replaces to=ibpX
3. routing decides that packet should go out from tun0
4. FORWARD chain considers (from=ipaZ, to=ippX)
5. packet leaves out from tun0
6. openvpn sends encrypted packet to ipaY
7. OUTPUT chain considers (from=ipA/opevpn, to=ipaY)
8. Packet leaves via eth0 to ipaY


You can verify whether traffic really occurs as I did describe and then deduce what rules are required in various chains in order to allow that traffic.