• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 961
  • Last Modified:

Cisco VPN router to access LAN behind IPCop firewall

We have a VPN setup to four remote locations and a corporate office. The office network is a 10.x.x.x network. The four remote locations are subnets 10.6.x.x, 10.7.x.x, 10.8.x.x, and 10.9.x.x. They are connected via Cisco routers, an 1841 Series at the corporate office and 861 Series at the remote location. In the past we had an ISA firewall that was removed when we took out a SBS 2003 server. As of now, we have an IPCop in its place. The remote networks are able to ping the server behind the IPCop firewall, at 10.0.0.2. They are unable to access any network resources. When we ran a traceroute to the server, it seemed to get stopped at the outside interface of the IPCop. After allowing ICMP traffic through the IPCop, we were able to get to the server with our ping requests.
While being able to ping the servers and other network resources is nice, we need to be able to access these resources. Not sure what protocols or rules to add at this point. Any suggestions?

Diagram
0
ruralsolutions
Asked:
ruralsolutions
  • 6
  • 5
1 Solution
 
Matt VCommented:
You need to allow SMB/CIFS (135, 137,138,139, 445)
0
 
ruralsolutionsAuthor Commented:
We tried to allow those with:

iptables -I CUSTOMFORWARD -p tcp --sport X -i eth1 -o eth0 --dport X -j ACCEPT

and by adding them to the external access list.

We had also done:

iptables -I CUSTOMFORWARD -i eth1 -o eth0 -p icmp -j ACCEPT

and that got pinging to work.  We did the same with the GRE protocol.

Still no cigar.
0
 
ruralsolutionsAuthor Commented:
By the way, eth1 is the RED interface and eth0 the GREEN interface.
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
Matt VCommented:
Try the following:

iptables -I CUSTOMFORWARD -p udp --dport 137:138 -j ACCEPT
 iptables -I CUSTOMFORWARD -p tcp --dport 139 -j ACCEPT
 iptables -I CUSTOMFORWARD -p tcp --dport 445 -j ACCEPT

Add your interface options as well if you want.
0
 
ruralsolutionsAuthor Commented:
That works GREAT!!! There is one problem though... It seems that the remote locations are not picking up DNS from the server, so they are not able to find the servers by name. I can get to them via IP, so I can go into the host files of all the remote PC's and add them to the list. I am hoping you know a better workaround though. Right now the remote clinics use the server as DNS1, the IPCop as DNS2 (as it was my understanding that the IPCop would pass DNS along) and the local ISP provider's DNS Servers for DNS 3&4.

Any suggestions?
0
 
Matt VCommented:
Secondary etc DNS are just for failover.. so the IPCop will only get asked if the server does not answer.  I would add the different networks to the server.  Even if you make different dns zones like subnet1.domain.local.

So you could have host1.subnet1.domain.local, host3.subnet4.domain.local etc.

Still better than remembering IPs :)
0
 
Matt VCommented:
Another thought, if these are all windows networks you can setup a WINS server at each subnet location, and have them all tie back to the main server.  This will resolve netbios names to IPs.
0
 
ruralsolutionsAuthor Commented:
Hmm... Now we are getting to a little beyond by knowledge. I have a reverse lookup zone per subnet. Not exactly sure if that is what you meant or not...
0
 
Matt VCommented:
No, just the forward lookup.  

You could write a batch script to copy the hosts file to the PCs at logon, then you would only have to maintain one copy :)
0
 
ruralsolutionsAuthor Commented:
Thanks, but we figured out how to get the DNS to register. We had to add these lines:

 iptables -I CUSTOMFORWARD -p udp --dport 53 -j ACCEPT
iptables -I CUSTOMFORWARD -p tcp --dport 53 -j ACCEPT

And DNS started working. Now we can get to all the machines we need to by name.

Thanks for your help!!!!
0
 
Matt VCommented:
Haha.. so obvious.. good stuff!
0

Featured Post

Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now