› Forums › Network Management › Firewall, Traffic Shaping and Net Balancer › openvpn firewall rules
- This topic is empty.
-
AuthorPosts
-
February 23, 2011 at 12:28 am #42873
zutthich
MemberHi Forum,
Please bear with me if my question is too basic.
I’ve put together an easy config just to test + learn zeroshell, where ETH00 is the LAN (192.168.5.75) and ETH01 is the WAN (192.168.2.3).
I want to be able to access my ZS via the WAN interface by SSH (i.e. putty + scp) and openvpn.
So far I’ve managed to connect to the ZS machine from the LAN side as well as going out the WAN side (for instance browsing).
I’ve managed also to enter with SSH + SCP via the WAN , but I’m still in high seas with OpenVPN and tunnelling.I thing the issue is with the “simple” rule needed to get the WAN side to open to port 1194. Can somebody please provide the right configuration instructions?
For your info I’ve attached the results of the two commands [iptables -L -vn] and [iptables -L -vn -t nat].Thanks for your help,
Induni
======================================
root@zeroshell root> iptables -L -vn
Chain INPUT (policy ACCEPT 84 packets, 19661 bytes)
pkts bytes target prot opt in out source destination
25301 3031K SYS_INPUT all — * * 0.0.0.0/0 0.0.0.0/0
0 0 SYS_HTTPS tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
252 35165 SYS_HTTPS tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
2356 171K SYS_SSH tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
2 1152 LOG all — ETH00 * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 15 LOG flags 0 level 4 prefix `INPUT/001′
2 1152 ACCEPT all — ETH00 * 0.0.0.0/0 0.0.0.0/0
3 148 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 Proxy tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:55559Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 LOG all — ETH00 * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 15 LOG flags 0 level 4 prefix `FORWARD/001′
0 0 ACCEPT all — ETH00 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHEDChain OUTPUT (policy ACCEPT 1889 packets, 381K bytes)
pkts bytes target prot opt in out source destination
24505 3056K SYS_OUTPUT all — * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp — * ETH01 0.0.0.0/0 0.0.0.0/0 udp spt:1194Chain NetBalancer (0 references)
pkts bytes target prot opt in out source destinationChain Proxy (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all — * * 0.0.0.0/0 0.0.0.0/0Chain SYS_HTTPS (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all — lo * 0.0.0.0/0 0.0.0.0/0
252 35165 ACCEPT all — * * 0.0.0.0/0 0.0.0.0/0Chain SYS_INPUT (1 references)
pkts bytes target prot opt in out source destination
21964 2625K ACCEPT all — lo * 0.0.0.0/0 0.0.0.0/0
377 94650 ACCEPT udp — * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 state ESTABLISHED
80 70469 ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state ESTABLISHED
0 0 ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp spt:8245 state ESTABLISHED
183 13908 ACCEPT udp — * * 0.0.0.0/0 0.0.0.0/0 udp spt:123 state ESTABLISHED
2697 227K RETURN all — * * 0.0.0.0/0 0.0.0.0/0Chain SYS_OUTPUT (1 references)
pkts bytes target prot opt in out source destination
21964 2625K ACCEPT all — * lo 0.0.0.0/0 0.0.0.0/0
389 30925 ACCEPT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
79 5286 ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8245
184 13984 ACCEPT udp — * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123
1889 381K RETURN all — * * 0.0.0.0/0 0.0.0.0/0Chain SYS_SSH (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all — lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all — * * 192.168.0.0/24 0.0.0.0/0
2356 171K ACCEPT all — ETH01 * 192.168.2.254 0.0.0.0/0
0 0 DROP all — * * 0.0.0.0/0 0.0.0.0/0
root@zeroshell root>
============================root@zeroshell root> iptables -L -vn -t nat
Chain PREROUTING (policy ACCEPT 56 packets, 11978 bytes)
pkts bytes target prot opt in out source destination
0 0 Proxy tcp — * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80Chain POSTROUTING (policy ACCEPT 2548 packets, 176K bytes)
pkts bytes target prot opt in out source destination
3120 221K SNATVS all — * * 0.0.0.0/0 0.0.0.0/0
572 44705 MASQUERADE all — * ETH01 0.0.0.0/0 0.0.0.0/0
2520 174K OpenVPN all — * * 0.0.0.0/0 0.0.0.0/0Chain OUTPUT (policy ACCEPT 3120 packets, 221K bytes)
pkts bytes target prot opt in out source destinationChain OpenVPN (1 references)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all — * * 0.0.0.0/0 0.0.0.0/0 source IP range 192.168.250.1-192.168.250.253Chain Proxy (1 references)
pkts bytes target prot opt in out source destinationChain SNATVS (1 references)
pkts bytes target prot opt in out source destination=================================
root@zeroshell root> ip route show default
192.168.5.0/24 dev ETH00 proto kernel scope link src 192.168.5.75
192.168.2.0/24 dev ETH01 proto kernel scope link src 192.168.2.3
192.168.0.0/24 dev ETH00 proto kernel scope link src 192.168.0.75
192.168.250.0/24 dev VPN99 proto kernel scope link src 192.168.250.254
default via 192.168.2.254 dev ETH01February 24, 2011 at 9:45 am #51609zutthich
MemberFor the benefit of other users I answer my own question:
In the firewall section, add one rule to the INPUT chain ACCEPTing from the interface connected to the outside world any packet with TCP protocol and Destination Port 1194 (or whatever port number you’ve chosen for OpenVPN)
Add one rule to the OUTPUT chain ACCEPTing to let TCP packets go out of the interface connected to the outside world and Destination Port as per above.
Then one has to add the rule(s) for the VPN packets proper.
If the VPN is considered just like another internal LAN, then the equivalent rule(s) can be added provided one choose the VPN interface.Induni
February 24, 2011 at 9:53 am #51610zutthich
MemberIn my case there was an issue derived from having added a new IP address to the LAN interface without deleting the setup 192.168.0.75 address.
Since the routing table still had the route for the original subnet, that created a problem with my specific settings. The environment ZS is in already contains an 192.168.0.0/24 subnet and the ZS routing instruction did not let packets return to the sender.
Dutifully deleting the original 192.168.0.75 address from the LAN interface fixed the problem.
-
AuthorPosts
- You must be logged in to reply to this topic.