Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Setting BM filters to allow NTP time sync

0 views
Skip to first unread message

ame...@news1.nf.sympatico.ca

unread,
Feb 1, 2007, 8:17:16 PM2/1/07
to
I have 2 servers that were in time sync until BM was set up on one.

They lost time synchronization, I assume it has to do with not being
able to reach a time source server.

In nwadmin, I can no longer access the BM setup, etc.., I get "The NDS
schema can not be extended, NDS error -659. Is this time synch problem
related?

I found a coolsolutions feature article indicating private to public
source/destination ports 123 for udp need to be open.

Where/how do I create the filter?

(Obviously new to BM filters - never did it before...help!)

Art

Caterina Luppi

unread,
Feb 2, 2007, 11:06:57 AM2/2/07
to
hi Art,

> They lost time synchronization, I assume it has to do with not being
> able to reach a time source server.

probably. Try to UNLOAD IPFLT and see if the time sync is working. On
the other hand, if you're using time sync within your organization (i.e.
not pointing to an external time source) it might mean that you have
applied the filters to the private interface of the BM server, that is
used to communicate with the rest of the servers and the edir.

> In nwadmin, I can no longer access the BM setup, etc.., I get "The NDS
> schema can not be extended, NDS error -659. Is this time synch problem
> related?

again, it's probably a filtering issue. If it's solved by UNLOAD IPFLT
at the console, you'll have to reset your filters.

> I found a coolsolutions feature article indicating private to public
> source/destination ports 123 for udp need to be open.
>
> Where/how do I create the filter?

As I said, it sound like a filtering issue, but you might have the
filters configured on the wrong interface.
Do you have two interfaces on the BM server, by the way?
Let me know if things look better after unloading IPFLT at the BM
console, and we can work from there.

--
Cat
NSC Volunteer Sysop

ame...@news1.nf.sympatico.ca

unread,
Feb 2, 2007, 2:35:14 PM2/2/07
to
Hi Cat,

Before installing BM both servers had a direct connection to the
internet via a cisco router. Now with BM on one server the other is
trying to contact the external time source but the BM server is between
it and the external sources (it is now on the private side of the BM
server).

So unloading ipflt made no difference.

The external time sources are at (from the ntp.conf file):

server 0.ca.pool.ntp.org
server 1.ca.pool.ntp.org
server 2.ca.pool.ntp.org

and the BM private interface is 192.168.50.250, the server trying to
contact the time source is at 192.168.50.251. The public interface is
now connected to the cisco router (at 10.251.12.255).

HTTP and access lists work, so connectivity is OK.

So how do I let my internal server contact the external time sources
throught the BM server?

TIA
Art

Caterina Luppi wrote:

> probably. Try to UNLOAD IPFLT and see if the time sync is working. On
> the other hand, if you're using time sync within your organization (i.e.
> not pointing to an external time source) it might mean that you have
> applied the filters to the private interface of the BM server, that is
> used to communicate with the rest of the servers and the edir.

> Do you have two interfaces on the BM server, by the way?

ame...@news1.nf.sympatico.ca

unread,
Feb 2, 2007, 2:37:56 PM2/2/07
to
Oh... I should add that yes, BM has two NICs one for private the other
public.


Caterina Luppi

unread,
Feb 5, 2007, 12:43:50 PM2/5/07
to
hi Art,

> Before installing BM both servers had a direct connection to the
> internet via a cisco router. Now with BM on one server the other is
> trying to contact the external time source but the BM server is between
> it and the external sources (it is now on the private side of the BM
> server).
>
> So unloading ipflt made no difference.

ok, so I think that you've the wrong default gateway in the server that
is trying to reach the NTP servers.

> and the BM private interface is 192.168.50.250, the server trying to
> contact the time source is at 192.168.50.251. The public interface is
> now connected to the cisco router (at 10.251.12.255).

Is the Bm server performing NAT?

Caterina Luppi

unread,
Feb 5, 2007, 2:24:55 PM2/5/07
to
Hi Art,

> You are probably right.
>
> How do check/set the default gateway (in the autoexec.ncf the gateway is
> the private BM address, is this right or should it be the public
> address, and is this only place to check?)

Are you sure your network stuff isn't in inetcfg? It should really be
there. Load inetcfg and if it prompts you, transfer the networking info
to it. Then in inetcfg go to protocols/tcpip and in the LAN routing you
can set the default gateway.

> In TCP/IP static routes it points to destination 0.0.0.0 and next hop is
> the router on the public side of the BM server.

ok, this is certainly not right. I tshould be the private IP of BM.

> No, NAT is not enabled.

this could be yet another issue. After having fixed the default gateway,
can the server ping the IP of the router on the public side of BM? If it
can't it's because the router needs a static route for the 192.168.x.x.
network you're using, with gateway=the public IP of the BM server.

ame...@news1.nf.sympatico.ca

unread,
Feb 5, 2007, 1:20:16 PM2/5/07
to
Hi Cat,

You are probably right.

How do check/set the default gateway (in the autoexec.ncf the gateway is
the private BM address, is this right or should it be the public
address, and is this only place to check?)

In TCP/IP static routes it points to destination 0.0.0.0 and next hop is

the router on the public side of the BM server.

No, NAT is not enabled.

Thanks for your help,
Art

ame...@news1.nf.sympatico.ca

unread,
Feb 5, 2007, 9:54:52 PM2/5/07
to
Caterina Luppi wrote:

> Hi Art,
>
>> You are probably right.
>>
>> How do check/set the default gateway (in the autoexec.ncf the gateway
>> is the private BM address, is this right or should it be the public
>> address, and is this only place to check?)
>
>
> Are you sure your network stuff isn't in inetcfg? It should really be
> there. Load inetcfg and if it prompts you, transfer the networking info
> to it. Then in inetcfg go to protocols/tcpip and in the LAN routing you
> can set the default gateway.
>
>> In TCP/IP static routes it points to destination 0.0.0.0 and next hop
>> is the router on the public side of the BM server.
>
> ok, this is certainly not right. I tshould be the private IP of BM.

I changed the TCP/IP static route on the time server so destination is
0.0.0.0 and next hop is the BM server private ip
address(192.168.50.250). Reinitialized, still can't ping the router
(10.251.12.254 - at least this is the default gateway, so I assume it is
the router?) but can ping the private ip of the BM server.

Just some more info - the BM public card is plugged into a switch
connected to the cisco router, as are eight other workstations. These
workstations can ping each other, and their default gateway
(10.251.12.254), but they can't ping the public card (10.251.12.225) in
the BM server, ping times out. When I try to ping any address on the
private side of the BM server from these workstations I get a reply back
from 10.251.253.93 that the destination is unreachable. Finally, if I
ping www.novell.com (or other well known hostname) I get back a resolved
IP address but still the message is destination is unreachable.

I guess the ISP has me inside a VPN? Any thoughts?

Thanks,
Art

Caterina Luppi

unread,
Feb 6, 2007, 11:42:49 AM2/6/07
to

> You are right, with the filters unloaded the ws on (10.251.12.xxx) can
> ping the BM public (10.251.12.225) side. Something works!

very good!

> No, must be on the other side of the router.

ok.

> Now what should I do? (Should I look into getting a static route in the
> router at 10.251.12.254?) Or....?

yes, the router has to have a static route like the one I described.

Caterina Luppi

unread,
Feb 6, 2007, 11:12:51 AM2/6/07
to
hi Art,

> I changed the TCP/IP static route on the time server so destination is
> 0.0.0.0 and next hop is the BM server private ip
> address(192.168.50.250). Reinitialized, still can't ping the router
> (10.251.12.254 - at least this is the default gateway, so I assume it is
> the router?) but can ping the private ip of the BM server.

ok, so it looks like the router (10.251.12.254) is missing a static
route entry for the 192.168.50.0/255.255.255.0 network, with the next
hop being the public IP of the BM server.

> Just some more info - the BM public card is plugged into a switch
> connected to the cisco router, as are eight other workstations. These
> workstations can ping each other, and their default gateway
> (10.251.12.254), but they can't ping the public card (10.251.12.225) in
> the BM server, ping times out.

Is this the case also with the filters unloaded? you might be blocking
ping with the filters.

> When I try to ping any address on the
> private side of the BM server from these workstations I get a reply back
> from 10.251.253.93 that the destination is unreachable.

Who is 10.251.253.93? is this a device in your network?
Again, if the router doesn't have a static route pointing to the BM
server for the 192.168.50.0/255.255.255.0 network, it will pass the
packets to your ISP, that obviously will drop it. I think that
10.251.253.93 might be a router in your ISP's domain.

> Finally, if I
> ping www.novell.com (or other well known hostname) I get back a resolved
> IP address but still the message is destination is unreachable.

ok, it looks like your ISP is blocking ICMP. That's not so strange.

> I guess the ISP has me inside a VPN? Any thoughts?

Certainly not a VPN. You're behind a firewall.

ame...@news1.nf.sympatico.ca

unread,
Feb 6, 2007, 11:40:16 AM2/6/07
to
Caterina Luppi wrote:

> hi Art,
>
>> I changed the TCP/IP static route on the time server so destination is
>> 0.0.0.0 and next hop is the BM server private ip
>> address(192.168.50.250). Reinitialized, still can't ping the router
>> (10.251.12.254 - at least this is the default gateway, so I assume it
>> is the router?) but can ping the private ip of the BM server.
>
>
> ok, so it looks like the router (10.251.12.254) is missing a static
> route entry for the 192.168.50.0/255.255.255.0 network, with the next
> hop being the public IP of the BM server.
>
>> Just some more info - the BM public card is plugged into a switch
>> connected to the cisco router, as are eight other workstations. These
>> workstations can ping each other, and their default gateway
>> (10.251.12.254), but they can't ping the public card (10.251.12.225)
>> in the BM server, ping times out.
>
>
> Is this the case also with the filters unloaded? you might be blocking
> ping with the filters.
>

You are right, with the filters unloaded the ws on (10.251.12.xxx) can
ping the BM public (10.251.12.225) side. Something works!

>


>> When I try to ping any address on the private side of the BM server
>> from these workstations I get a reply back from 10.251.253.93 that the
>> destination is unreachable.
>
>
> Who is 10.251.253.93? is this a device in your network?

No, must be on the other side of the router.

> Again, if the router doesn't have a static route pointing to the BM

> server for the 192.168.50.0/255.255.255.0 network, it will pass the
> packets to your ISP, that obviously will drop it. I think that
> 10.251.253.93 might be a router in your ISP's domain.
>
>> Finally, if I ping www.novell.com (or other well known hostname) I get
>> back a resolved IP address but still the message is destination is
>> unreachable.
>
>
> ok, it looks like your ISP is blocking ICMP. That's not so strange.
>
>> I guess the ISP has me inside a VPN? Any thoughts?
>
>
> Certainly not a VPN. You're behind a firewall.
>

Now what should I do? (Should I look into getting a static route in the
router at 10.251.12.254?) Or....?

Thanks again,
Art

ame...@cdli.ca

unread,
Feb 7, 2007, 8:51:21 AM2/7/07
to
Hi again Cat,

I requested to the powers that be (as I have no control over the router I
connect the BM public side to) to implement in that router the static route
- here is the response I got back:

"Art, have you thought about using a small router to do NAT for your
subnet. The router could port forward to the server to allow port 123
traffic (NTP). The router would handle the 192.x.x.x network and
filtering can be done to deny access to specific sites or protocols."

Would this work for me?

Could the BM server do this? (The router role he refers to.)

Thanks again,
Art

Caterina Luppi

unread,
Feb 7, 2007, 10:17:00 AM2/7/07
to
Art,

> "Art, have you thought about using a small router to do NAT for your
> subnet. The router could port forward to the server to allow port 123
> traffic (NTP). The router would handle the 192.x.x.x network and
> filtering can be done to deny access to specific sites or protocols."

you don't need a small router for that. BM can do that for you by
configuring dynamic NAT.

ame...@news1.nf.sympatico.ca

unread,
Feb 7, 2007, 2:37:17 PM2/7/07
to
Caterina Luppi wrote:
>
> you don't need a small router for that. BM can do that for you by
> configuring dynamic NAT.

Super!, I will look into configuring dynamic nat for my time server. I
will post in NAT forum if I run into problems (likely).

Many Thanks,
Art

Caterina Luppi

unread,
Feb 7, 2007, 6:58:52 PM2/7/07
to

> Super!, I will look into configuring dynamic nat for my time server. I
> will post in NAT forum if I run into problems (likely).

since your time server doesn't need to be accessed from the outside, but
it needs to access the internet, you won't install dynamic nat *for your
router* but for all your private IP addresses.

ame...@news1.nf.sympatico.ca

unread,
Feb 7, 2007, 7:32:49 PM2/7/07
to
Oh-oh, now you are scaring me.

After my last post, I used Inetcfg on the BM server to turn on dynamic
nat on the public interface. After a reboot - yippee - time synchronised!

1. Now what do you mean by turning it on but not *for your router*?

And while I am at it, a few more "routing/filtering for dummies" questions.

2. Do the filters apply to the router and/or dynamic NATted packets? (I
am guessing they do...)

3. Do filters apply to the proxied stuff? (I am guessing they don't,
instead ACL handles that...)


3. I made stateful filter exceptions for the time server's address to
access the public interface before I turned NAT on. I was going to
delete those as they didn't seem to work. Should I? (I am thinking I
shouldn't because they are probably the reason NAT seemed to work right
away...)

Sorry for all the questions.

Thanks
Art

Caterina Luppi

unread,
Feb 8, 2007, 8:49:30 AM2/8/07
to

> 1. Now what do you mean by turning it on but not *for your router*?

sorry, I must have been interrupted when I was typing, and I got it out
wrong. I meant that NAT won't serve only for your NTP server (I wrote
router by mistake), but it will be applied to ALL of your internal IP
addresses. The result is that whatever comes out of your LAN will look
as if it comes from the public IP of BM.

> 2. Do the filters apply to the router and/or dynamic NATted packets? (I
> am guessing they do...)

absolutely!

> 3. Do filters apply to the proxied stuff? (I am guessing they don't,
> instead ACL handles that...)

they do, as well. Everything has to go through the packet filters, the
difference is that for proxied traffic the filters believe that they're
originated by the proxy, instead of being originated by the
workstations, while for the not proxied traffic (like your NTP packets),
the filters see the real origin IP address of the packets.
The ACL work only on the proxied traffic, first deciding if a request is
appropriate from the point of view of the access rules, and then
forwarding the packets to the packet filters.
Clearer? Just a bit clearer? :-)

> 3. I made stateful filter exceptions for the time server's address to
> access the public interface before I turned NAT on. I was going to
> delete those as they didn't seem to work. Should I? (I am thinking I
> shouldn't because they are probably the reason NAT seemed to work right
> away...)

No, you shouldn't. If you didn't have these the NTP wouldn't work.

> Sorry for all the questions.

no problem! That's what we're here for.

ame...@news1.nf.sympatico.ca

unread,
Feb 8, 2007, 12:14:52 PM2/8/07
to
Caterina Luppi wrote:
>
> Clearer? Just a bit clearer? :-)
>

Be careful, I'll soon know as much as you! :-)
My mind is at ease. (for now)

>
> no problem! That's what we're here for.
>

Good job you are! An apple for your desk, teach.

Many,many thanks.
Art

Caterina Luppi

unread,
Feb 8, 2007, 3:32:33 PM2/8/07
to

> Be careful, I'll soon know as much as you! :-)
> My mind is at ease. (for now)

Phew :-)

> Good job you are! An apple for your desk, teach.
>
> Many,many thanks.

you're very welcome!

0 new messages