How to configure Firewall for VPN on a server with two IPs

I finally got myself a server. He placed the site of his "company" on it, and in the neighborhood decided to raise VPN. For this was ordered the second IP. On the first, I will have web, mail, ssh and from the second there will be VPN traffic. The idea is simple, but I never found a good description of such a configuration. Under the cut, I'll show you how to configure Shorewall so that VPN traffic goes only to the Internet, and could not freely pass to the next IP.

In this post I want to focus not on installing all the programs, it has been described many times including on the habre, but on setting up a firewall for the situation when all the network interfaces are on the same map. To control the firewall, I will use the Shorewall package. Shorewall has a lot of documentation on the site, but it basically describes configurations with separate network cards and subnets behind them.

Let's first look at ifconfig. There we see our two IP-shnik, "1.1.1.1" and "2.2.2.2". They both go directly to the Internet. Now they are "twins", that is, if any service is spinning on the first, it will be visible on the second IP.
')

# ifconfig eth0 Link encap:Ethernet HWaddr ::::: inet addr:1.1.1.1 Bcast:1.1.1.255 Mask:255.255.255.0 inet6 addr: fe80:::::/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:417428 errors:0 dropped:230 overruns:0 frame:0 TX packets:17595 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:28249193 (28.2 MB) TX bytes:4653027 (4.6 MB) eth0:0 Link encap:Ethernet HWaddr ::::: inet addr:2.2.2.2 Bcast:2.2.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:507 errors:0 dropped:0 overruns:0 frame:0 TX packets:507 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:44121 (44.1 KB) TX bytes:44121 (44.1 KB) 

Let's cover this case, so that 1.1.1.1 skip to the web, email, ssh, and 2.2.2.2 listen to vpn. Here is the configuration:

 # cat /etc/shorewall/interfaces #ZONE INTERFACE BROADCAST OPTIONS net4 eth0 detect tcpflags,logmartians,nosmurfs # cat /etc/shorewall/zones #ZONE TYPE OPTIONS IN OUT fw firewall net4 ipv4 # cat /etc/shorewall/policy #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: $FW net4 ACCEPT net4 $FW DROP info net4 all DROP info # The FOLLOWING POLICY MUST BE LAST all all REJECT info # cat /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST SOURCE SECTION NEW # ------------------------- INTERNET -------------------------------- ACCEPT net4 $FW:1.1.1.1 tcp 22 ACCEPT net4 $FW:1.1.1.1 tcp 25 ACCEPT net4 $FW:1.1.1.1 tcp 80 # ------------------------- VPN ------------------------------------- ACCEPT net4 $FW:2.2.2.2 udp 1194 

This is the standard configuration, which allows all traffic from our VPS-a to the Internet, and does not allow anything back except what is written in the rules. The $ FW zone means both IPs, since both are part of eth0 (despite the fact that 2.2.2.2 has its own name eth0: 0). For clarification, use is made of the type: $ FW: [ip]. It feels good. Then, we start the VPN server, and we watch ifconfig. Besides the fact that there was already there, a new interface tun0 appeared:

 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 PtP:10.1.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3261 errors:0 dropped:0 overruns:0 frame:0 TX packets:2624 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:351155 (351.1 KB) TX bytes:1043254 (1.0 MB) 

Note that the tun0 interface is not a “twin” with eth0, but is a more complete interface. VPN clients will sit behind this subnet. Let's connect right now. On another computer: we pass authorization, the connection is established, go to the terminal and try to connect at least to our vpn gateway (10.8.0.1) to read mail, you can ping if pings are accepted (see /etc/sysctl.conf).

 $telnet 10.8.0.1 25 $sudo tail /var/log/syslog ... Shorewall:INPUT:REJECT:IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 ... PROTO=TCP SPT=36879 DPT=25 ... 

Our attempt to access the mail server was rejected, due to the fact that, not being a “twin” eth0, tun0, we cannot speak to eth0 (and eth0: 0) because of the rule:

 all all REJECT info 

at the end of / etc / shorewall / policy. So far, all right. Then add tun0 to shorewall.
New configuration:

 # cat /etc/shorewall/interfaces #ZONE INTERFACE BROADCAST OPTIONS net4 eth0 detect tcpflags,logmartians,nosmurfs vpn4 tun0 detect tcpflags,logmartians,nosmurfs #NEW # cat /etc/shorewall/zones #ZONE TYPE OPTIONS IN OUT fw firewall net4 ipv4 vpn4 ipv4 #NEW # cat /etc/shorewall/policy #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: $FW net4 ACCEPT vpn4 $FW ACCEPT #NEW vpn4 net4 ACCEPT #NEW net4 $FW DROP info net4 all DROP info # The FOLLOWING POLICY MUST BE LAST all all REJECT info # cat /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST SOURCE SECTION NEW # ------------------------- INTERNET -------------------------------- ACCEPT net4 $FW:1.1.1.1 tcp 22 ACCEPT net4 $FW:1.1.1.1 tcp 25 ACCEPT net4 $FW:1.1.1.1 tcp 80 # ------------------------- VPN ------------------------------------- ACCEPT net4 $FW:2.2.2.2 udp 1194 # SNAT, for access to internet -- NEW # cat /etc/shorewall/masq #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK eth0 10.8.0.0/24 2.2.2.2 

What changed? We created a zone called vpn4 which corresponds to the tun0 interface. We declared vpn4 as IPv4. We allowed traffic from tun0 to reach the firewall, and the Internet (eth0 / net4). Strangely enough, it cannot be allowed only to the firewall, and then according to the existing rule $ fw -> net4. You need to add both lines. And the last thing we need for a full-fledged access to the Internet is SNAT (source address translation, when the sender's address is replaced with the address that is looking to the Internet, in our case 2.2.2.2). We create the masq file and demand that all the addresses of 10.8.0.x be replaced by 2.2.2.2 when exiting eth0 (and eth0: 0).

We try ... Everything works! Even too ... with the address from 10.8.0.x you can go to 1.1.1.1:11:1194, which we do not want. We wanted to vpn traffic first went on the Internet and then beat back through the firewall. Instead, we have a vpn client that looks at our server from behind. Why? Because when we allowed communication like:

 # /etc/shorewall/policy: vpn4 $FW ACCEPT #NEW 

we did not specify which IP, since there are two under $ FW (1.1.1.1 and 2.2.2.2). Well, let's prescribe. But no, syntax of the type: $ FW: [ip] in the policy file is not accepted. At this point, I tried a lot of things and almost abandoned the idea and left as is. Although the end of the road was very small. So, insight: everything that is prescribed in a policy can also be specified in the rules, and in the rules we can specify specific IP on the firewall-e. Let's rewrite the latest configuration:

 # cat /etc/shorewall/interfaces #ZONE INTERFACE BROADCAST OPTIONS net4 eth0 detect tcpflags,logmartians,nosmurfs vpn4 tun0 detect tcpflags,logmartians,nosmurfs # cat /etc/shorewall/zones #ZONE TYPE OPTIONS IN OUT fw firewall net4 ipv4 vpn4 ipv4 # cat /etc/shorewall/policy #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: $FW net4 ACCEPT #vpn4 $FW ACCEPT #NEW #vpn4 net4 ACCEPT #NEW net4 $FW DROP info net4 all DROP info # The FOLLOWING POLICY MUST BE LAST all all REJECT info # cat /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST SOURCE SECTION NEW # ------------------------- INTERNET -------------------------------- ACCEPT net4 $FW:1.1.1.1 tcp 22 ACCEPT net4 $FW:1.1.1.1 tcp 25 ACCEPT net4 $FW:1.1.1.1 tcp 80 # ------------------------- VPN ------------------------------------- ACCEPT net4 $FW:2.2.2.2 udp 1194 # ------------------------- NEW ------------------------------------- ACCEPT vpn4 net4 ACCEPT vpn4 $FW:1.1.1.1 tcp 22 ACCEPT vpn4 $FW:1.1.1.1 tcp 25 ACCEPT vpn4 $FW:1.1.1.1 tcp 80 # cat /etc/shorewall/masq #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK eth0 10.8.0.0/24 2.2.2.2 

What we did: removed the old permissions from the policy, and added the permissions in the rules. We allow all traffic from vpn to the Internet, and selectively allow traffic directly to 1.1.1.1. And via the Internet, calls to 1.1.1.1 cannot be sent? No, no matter how much we want, they will go inside the server, so the best we can do is duplicate the rules for the Internet for vpn traffic -> 1.1.1.1. But what about traffic on 2.2.2.2? This traffic directly is the vpn traffic, and it cannot come from the inside (this is followed by the route on the client machine). In other words, the vpn-a client will never send traffic in the direction of 10.8.0.1 (vpn4) -> 2.2.2.2 ($ fw: 2.2.2.2).

Well, that's basically all. Now we can safely browse from the "working" VPN-a without using the IP address of the host on the "companion" site, and are not afraid to bypass the firewall with the usual vpn users.