1605-R NAT - need WS on outside interface in

[smkiat]

Here is a crude picture of the topology:

192.168.0.x<--->192.168.0.1/e1-c1605-e0/1.1.1.1<--->1.1.1.x*

*e0 address space has been changed to protect the innocent since it is public address space

The PCs in the 192.168.0.x subnet were originally slated to access the Internet through a new DSL circuit. This would have put a new firewall in the same subnet. The 1605 was to be configured to allow the accountant in the 1.1.1.x subnet (1.1.1.10) to map a drive to a share on the server (192.168.0.2) in the 192.168.0.x subnet. Since the businesses in question are in the medical field the networks must be separated to meet HIPAA requirements. If this was the end of it then configuring the router would be within my skill set.

Even though the office next door (1.1.1.x) has DSL a new DSL circuit for the 192.168.0.x location is not available for the forseeable future. Frame Relay or Fractional T1 are too much money at this time. Therefore sharing the DSL connection in the 1.1.1.x subnet with the 192.168.0.x subnet is a priority.

Herein lies the problem. The exisitng Watchguard SOHO Firewall has an internal ip of 1.1.1.5. Any packets not in the 1.1.1.x subnet are dropped. I can enable NAT on the 1605 and successfully access the Internet from the 192.168.0.x subnet by natting to the 1.1.1.1 interface (e0/outside on 1605). However, the accountant's WS (1.1.1.10) can no longer reach the Server at 192.168.0.2 since it is on the outside interface of the 1605.

I have worked on this long enough to end up with the accountant's WS (1.1.1.10) able to ping and tracert to the server (192.168.0.2). I have also set up a hosts file and can ping the server by name from the accountants WS (1.1.1.10). All this with NAT enabled on the 1605 and the 1.1.1.x subnet configured as outside. I am a long way from being a Cisco Guru but I am guessing that the ICMP packets are transiting the router's interfaces. However, I am further guessing, the protocols/ports needed for MS networking are being dropped. It is not possible to map a drive nor connect in any way (other than replies to pings) to the server at 192.168.0.2 with NAT enabled on the 1605.

Am I dreaming or is there a way to get this to work?

[Georg Pauwen]

Hello,

can you post the configuration of the 1605 ? Since you say the PING and TRACEROUTE work, I wonder if the access list you use for NAT can cause the problem.

Regards,

Georg

[smkiat]

Georg,

Here is the current config. I have tried multiple others including some with ACLs. Keep in mind this separates two networks in adjacent office suites. Therefore I am not concerned about locking down ACLs if used.

Thanks

Sean

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname imr_1605r

!

enable secret xxxxxxxxxxx

enable password xxxxxxxxxxx

!

ip subnet-zero

!

!

!

interface Ethernet0

description Urology NW outside-e0

ip address 1.1.1.1 255.255.255.0

no ip directed-broadcast

ip nat outside

!

interface Ethernet1

description Integrity Medical Research inside-e1

ip address 192.168.0.1 255.255.255.0

no ip directed-broadcast

ip nat inside

!

ip nat pool UNW 1.1.1.1 1.1.1.1 netmask 255.255.255.0

ip nat inside source list 1 pool UNW overload

ip classless

ip route 0.0.0.0 0.0.0.0 1.1.1.5

ip route 192.168.0.0 255.255.255.0 1.1.1.0

ip route 1.1.1.0 255.255.255.0 192.168.0.0

!

!

line con 0

exec-timeout 0 0

password 7 045205125C265E471D00

login

transport input none

line vty 0 4

password 7 151B0518572D392D3C2A

login

!

end

[thisisshanky]

Hello there,

I think , the only thing you need to do here, is to, ask the router to forward your Netbios requests. Netbios over TCP/IP is used in MS networking. Ports used are 137, 138 and 139.

Give a helper-address statement on the E0 interface (1.1.1.x subnet) as follows.

int e0

ip helper-address 192.168.0.2

This would help in Netbios broadcast (request, queries etc, on port 137, 138 and 139) to be forwarded as unicast to 192.168.0.2

[smkiat]

Thanks for the info about "helper-address". I had tried some ACLs with both UDP and TCP ports 137, 138 & 139 but hadn't made any headway. Possibly because I did not have the proper syntax. I'll check the helper-address scenario.

Thanks,

Sean