Mapping drive to Samba share in another subnet issue
Hi there,
I'm relatively new to Samba so I hope this isn't too much of a noob
question. I have an AIX server running Samba 2.2.7 (unable to update
to 3.0.x due to OS version) that I'd like to be able to get Windows XP
clients to map a drive to the Samba shares I've created. When the XP
machines and the Samba server are on the same subnet, it works great.
When I move the server to a different subnet, any pre-existing XP
drive mappings still work but I'm not able to recreate the mappings.
All traffic seems to be passing back and forth through the firewall
but for whatever reason, I've tried NAT'ing the IP for the Samba
server as well as just do a straight routing to the private IP of the
Samba server - nothing seems to work.
Any help with this would be greatly appreciated.
Thanks!
Re: Mapping drive to Samba share in another subnet issue
On 2007-06-25, Rick H <rick.hislop@gmail.com> wrote:[color=blue]
> Hi there,
> I'm relatively new to Samba so I hope this isn't too much of a noob
> question. I have an AIX server running Samba 2.2.7 (unable to update
> to 3.0.x due to OS version) that I'd like to be able to get Windows XP
> clients to map a drive to the Samba shares I've created. When the XP
> machines and the Samba server are on the same subnet, it works great.
> When I move the server to a different subnet, any pre-existing XP
> drive mappings still work but I'm not able to recreate the mappings.
> All traffic seems to be passing back and forth through the firewall
> but for whatever reason, I've tried NAT'ing the IP for the Samba
> server as well as just do a straight routing to the private IP of the
> Samba server - nothing seems to work.
>
> Any help with this would be greatly appreciated.[/color]
Assuming that Samba works the same way "real" Windows does, there's
some broadcast nonsense that needs carrying between the subnets (sorry
to be a bit vague - I haven't been involved with the dark side for some
years). What we used to do was define "helper" addresses on the Cisco
kit, such that all tcp/udp broadcasts using ports 137, 138 & 139
were carried across the routers, which normally drop broadcasts.
There may be a better way of doing it now ...
--
"If only I had known, I should have become a watchmaker." ~ Albert Einstein
[email me at huge {at} huge (dot) org <dot> uk]
Re: Mapping drive to Samba share in another subnet issue
On Jun 25, 11:26 pm, Huge <H...@nowhere.much.invalid> wrote:[color=blue]
> On 2007-06-25, Rick H <rick.his...@gmail.com> wrote:
>[color=green]
> > Hi there,
> > I'm relatively new to Samba so I hope this isn't too much of a noob
> > question. I have an AIX server running Samba 2.2.7 (unable to update
> > to 3.0.x due to OS version) that I'd like to be able to get Windows XP
> > clients to map a drive to the Samba shares I've created. When the XP
> > machines and the Samba server are on the same subnet, it works great.
> > When I move the server to a different subnet, any pre-existing XP
> > drive mappings still work but I'm not able to recreate the mappings.
> > All traffic seems to be passing back and forth through the firewall
> > but for whatever reason, I've tried NAT'ing the IP for the Samba
> > server as well as just do a straight routing to the private IP of the
> > Samba server - nothing seems to work.[/color]
>[color=green]
> > Any help with this would be greatly appreciated.[/color]
>
> Assuming that Samba works the same way "real" Windows does, there's
> some broadcast nonsense that needs carrying between the subnets (sorry
> to be a bit vague - I haven't been involved with the dark side for some
> years). What we used to do was define "helper" addresses on the Cisco
> kit, such that all tcp/udp broadcasts using ports 137, 138 & 139
> were carried across the routers, which normally drop broadcasts.
>
> There may be a better way of doing it now ...
>
> --
> "If only I had known, I should have become a watchmaker." ~ Albert Einstein
> [email me at huge {at} huge (dot) org <dot> uk][/color]
Thanks. I'll see what I can do with the firewall policies to help it
along.
Cheers,
Rick