Sonicwall TZ100 - does it work as a NAT router by default?

In the firewall rules I see Allow All for LAN > WAN (which is right)
but only Deny All for WAN > LAN (which is also right, but not for
sessions established earlier using a LAN > WAN connection.

Is this really right? The router will not work at all if that is how
it comes up.

Sonicwall provide some limited support but the login details they
emailed me don't work, even though I have confirmed the account
creation email

Much appreciate any tips...

I can ping IPs via both ethernet and wifi connections OK, but DNS
doesn't work.

It doesn't even work from the router itself, because it cannot access
the Sonicwall registration site, saying that there is no DNS.

I found this
http://help.expedient.com/broadband/sonic_wall.shtml

which may be relevant, because (like that article) I am connecting to
ZEN via the Draytek Vigor 120 whose ethernet interface is PPPOE.

Can anyone suggest a solution?

I've spent a few hours on it now. I got into the Sonicwall support
site eventually, downloaded the latest (non beta) firmware (which was
2011 whereas the existing firmware was 2009; curious for a brand new
router from Insight UK), installed that (which required a key to be
obtained from Sonicwall... why do they secure their products like
this???), reconnected to ZEN, but still cannot get any DNS.

I cannot see any appnotes on the web for the Vigor 120 and Sonicwall
routers, either. Of course Vigor provide no support.

Peter wrote:
> In the firewall rules I see Allow All for LAN > WAN (which is right)
> but only Deny All for WAN > LAN (which is also right, but not for
> sessions established earlier using a LAN > WAN connection.
>
> Is this really right? The router will not work at all if that is how
> it comes up.

It is right, i you uinersatnd how TCP works.

To initiate a session, you send a specific packet type. Once initiated,
teh packets sent have an established session number, which the router
recognises as being part of the session initiated from inside the local
network. Thats how NAT works..it 'remembers ' that 'tahts ession is to
do with that PC' and routes the packets to the local address.
The deny all applies to the OPEN PORT packets only. Established
connections are allowed through.

Howver with NAT that happens anyway so the firewall is simply a belt
AND trousers.

Itc becomes relevant only when you have configured pass through so that
SOME incoming requests to open ports DO get through to a server. THEN
you might want to allow them through the firewall, but only - say - from
a specific IP address. I have used that to be able to remotely access
servers, but only from my (fixed) IP address.

in general for simple firewalls the rules only apply to port open requests.

It can get deeper than that..
>
> Sonicwall provide some limited support but the login details they
> emailed me don't work, even though I have confirmed the account
> creation email
>
> Much appreciate any tips...

I have sent back the TZ100 because there was probably something wrong
with it, but doing more googling today, and also looking at some
recent Draytek stuff, it looks like there are basic issues resolving
DNS over PPPoE.

This
http://help.expedient.com/broadband/sonic_wall.shtml
suggests that it simply does not work, and that the Sonicwall router
has to have a nameserver IP manually configured in it.

This
http://www.draytek.com/.upload/Demo/Vigor2920/v3.3.6.1/
WAN / Internet Access / WAN1 / PPPoE / Details Page

does not show any config for getting an IP assigned dynamically from
the ISP.

Whereas if you did
WAN / Internet Access / WAN1 / Static or Dynamic IP / Details Page

you see the "Obtain an IP address automatically" option there. That
would be the config used with a conventional ADSL modem e.g. the old
D-Link 300.

The above Draytek stuff is for the 2920 which is still a current
product.

Looking in my 2900 router config, I see the same stuff but the menus
are structured a bit differently. Again, PPPoE doesn't have an "Obtain
an IP address automatically" option; the 2900 has it elsewhere but on
this router (which talks PPPoE to the Draytek 120 modem) that option
is UNchecked anyway.

So how does DNS work in the 2900 or 2920, when they are configured for
PPPoE?

I know little about this but my guess is that DNS is implicit in the
PPPoE protocol i.e. it is done all the way from the ISP. So if e.g.
you do
ping www.cisco.com
the "www.cisco.com" string gets sent to the ISP and the ISP then
returns the corresponding IP.

On the 2900 router which uses PPPoE via the Draytek 120, there are
currently two PCs running. One has a fixed IP on the LAN and one has a
dynamic IP, allocated by the router's DHCP server. The former has a
DNS entry of 8.8.8.8 (because if you specify a fixed IP in windoze's
TCP/IP config, you also have to specify the DNS IP manually). The
latter's DNS entry is 192.168.10.1 which is the gateway IP, the
router's config IP, etc.

DNS works fine on BOTH of these PCs. It should work anyway on the
former due to the 8.8.8.8 but how does it work on the latter? That one
must be going to the router for DNS.

Yes there is NO config for DNS in the router, so it must be getting
the DNS resolution by making some kind of call all the way back to the
ISP.

And that is the bit which did not work on the Sonicwall TZ100.

Does this make sense?

In article <(E-Mail Removed)>,
Peter <(E-Mail Removed)> wrote:

>Looking in my 2900 router config, I see the same stuff but the menus
>are structured a bit differently. Again, PPPoE doesn't have an "Obtain
>an IP address automatically" option; the 2900 has it elsewhere but on
>this router (which talks PPPoE to the Draytek 120 modem) that option
>is UNchecked anyway.
>
>So how does DNS work in the 2900 or 2920, when they are configured for
>PPPoE?
>
>I know little about this but my guess is that DNS is implicit in the
>PPPoE protocol i.e. it is done all the way from the ISP. So if e.g.
>you do
>ping www.cisco.com
>the "www.cisco.com" string gets sent to the ISP and the ISP then
>returns the corresponding IP.
>
>On the 2900 router which uses PPPoE via the Draytek 120, there are
>currently two PCs running. One has a fixed IP on the LAN and one has a
>dynamic IP, allocated by the router's DHCP server. The former has a
>DNS entry of 8.8.8.8 (because if you specify a fixed IP in windoze's
>TCP/IP config, you also have to specify the DNS IP manually). The
>latter's DNS entry is 192.168.10.1 which is the gateway IP, the
>router's config IP, etc.
>
>DNS works fine on BOTH of these PCs. It should work anyway on the
>former due to the 8.8.8.8 but how does it work on the latter? That one
>must be going to the router for DNS.
>
>Yes there is NO config for DNS in the router, so it must be getting
>the DNS resolution by making some kind of call all the way back to the
>ISP.
>
>And that is the bit which did not work on the Sonicwall TZ100.
>
>Does this make sense?

Er, ... Sort os.

DNS is just another Internet based service. A client has what's known as
a "stub resolver" which is often just enough code to contact another DNS
server to do the name to number translation for you. To contact another
resolver basically it just needs the IP address(es).

Resolvers can be simple caching resolvers whereby they know how to talk to
"proper" resolvers, and just remember the data for next time, or "proper"
resolvers that can query other resolvers in a recursive manner. (DNS is
effectively a huge global database)

PPPoE is just a transport mechanism. As part of the PPP negotiation at
startup time (username, password), the PPP session has the abiltiy to get
the IP addresses of the remote ISPs DNS servers (if they supply them which
most do), - which it can then use to resolve names into numbers itself.

What then usually happens is that the router running the PPP(oe/oa)
session, puts these IP addresses into it's local DHCP configuration (if
it's acting as a DHCP server) to pass onto clients - clients then use
that IP address (as part of their stub resolver) to do the name to number
translation. Sometimes it hangs onto these IP addresses and passes out
it's own IP address to clients - and it then acts as a caching resolver
for clients on the LAN.

8.8.8.8 and 8.8.4.4 are Googles own public-facing DNS resolvers.

So on the client that's using DHCP, check it's nameservers - it's probably
gotten them via the DHCP server on the 2900 and might be pointing either
to the Draytek or to the ISPs own servers.

Drayteks typically pass out their own IP address to clients and then
act as a caching nameserver. In theoy it ought to help a little -
e.g. everyone going to news.bbc.co.uk in the morning only needs one
DNS lookup.

Gordon

Gordon Henderson wrote:
> In article <(E-Mail Removed)>,
> Peter <(E-Mail Removed)> wrote:
>
>> Looking in my 2900 router config, I see the same stuff but the menus
>> are structured a bit differently. Again, PPPoE doesn't have an "Obtain
>> an IP address automatically" option; the 2900 has it elsewhere but on
>> this router (which talks PPPoE to the Draytek 120 modem) that option
>> is UNchecked anyway.
>>
>> So how does DNS work in the 2900 or 2920, when they are configured for
>> PPPoE?
>>
>> I know little about this but my guess is that DNS is implicit in the
>> PPPoE protocol i.e. it is done all the way from the ISP. So if e.g.
>> you do
>> ping www.cisco.com
>> the "www.cisco.com" string gets sent to the ISP and the ISP then
>> returns the corresponding IP.
>>
>> On the 2900 router which uses PPPoE via the Draytek 120, there are
>> currently two PCs running. One has a fixed IP on the LAN and one has a
>> dynamic IP, allocated by the router's DHCP server. The former has a
>> DNS entry of 8.8.8.8 (because if you specify a fixed IP in windoze's
>> TCP/IP config, you also have to specify the DNS IP manually). The
>> latter's DNS entry is 192.168.10.1 which is the gateway IP, the
>> router's config IP, etc.
>>
>> DNS works fine on BOTH of these PCs. It should work anyway on the
>> former due to the 8.8.8.8 but how does it work on the latter? That one
>> must be going to the router for DNS.
>>
>> Yes there is NO config for DNS in the router, so it must be getting
>> the DNS resolution by making some kind of call all the way back to the
>> ISP.
>>
>> And that is the bit which did not work on the Sonicwall TZ100.
>>
>> Does this make sense?
>
> Er, ... Sort os.
>
> DNS is just another Internet based service. A client has what's known as
> a "stub resolver" which is often just enough code to contact another DNS
> server to do the name to number translation for you. To contact another
> resolver basically it just needs the IP address(es).
>
> Resolvers can be simple caching resolvers whereby they know how to talk to
> "proper" resolvers, and just remember the data for next time, or "proper"
> resolvers that can query other resolvers in a recursive manner. (DNS is
> effectively a huge global database)
>
> PPPoE is just a transport mechanism. As part of the PPP negotiation at
> startup time (username, password), the PPP session has the abiltiy to get
> the IP addresses of the remote ISPs DNS servers (if they supply them which
> most do), - which it can then use to resolve names into numbers itself.
>
> What then usually happens is that the router running the PPP(oe/oa)
> session, puts these IP addresses into it's local DHCP configuration (if
> it's acting as a DHCP server) to pass onto clients - clients then use
> that IP address (as part of their stub resolver) to do the name to number
> translation. Sometimes it hangs onto these IP addresses and passes out
> it's own IP address to clients - and it then acts as a caching resolver
> for clients on the LAN.
>
> 8.8.8.8 and 8.8.4.4 are Googles own public-facing DNS resolvers.
>

DBS servers,. not resolver. A resolver is a client side issue.

> So on the client that's using DHCP, check it's nameservers - it's probably
> gotten them via the DHCP server on the 2900 and might be pointing either
> to the Draytek or to the ISPs own servers.
>
> Drayteks typically pass out their own IP address to clients and then
> act as a caching nameserver. In theoy it ought to help a little -
> e.g. everyone going to news.bbc.co.uk in the morning only needs one
> DNS lookup.
>
> Gordon


Pretty good, but simplified explanation may be in order.

The stub resolvers in your PCs need to know one or two 'better'
nameservers to ask.

How it knows where those are is set up in two ways,.

1/. by directly specifiying them on the PC itself.
2/. By having the local DHCP server (the router) supply them as part of
the DHCP protocol.

Likewise the router itself gets ITS notion of what DNS to use (and its
IP address) by an entirely separate PPP process when it logs into the ISP.

It gets worse. The router may decide to dish out these DNS addresses as
part of its DHCP conversation with the PC OR it may be set up to act as
a caching server ITSELF in which case it will dish out its OWN IP
address. Or optionally you can set up completely arbitrary DNS address
to be dished out as part of the router configuration!

Even if you use your ISPs 'preferred DNS server' that itself may be
prone to cockups.

Having suffered for many years I take the route of running my OWN
nameserver. At least that way I can fix it when it breaks.

alexd <(E-Mail Removed)> wrote

>No. The application, in this case ping, will resolve the IP address first,
>and send the ICMP echo to that IP address. In other words, your PC will need
>to have an idea of how to resolve IP addresses, usually by contacting a DNS
>server.

OK, but take a client PC whose TCP/IP DNS is e.g. 192.168.1.1 which is
the router IP.

Ignoring caching, in that case the *router* has to go and sort out the
DNS.

But, as in my config examples, a router which is connected via PPPoE
has no config for a DNS server (e.g. 8.8.8.8 or more properly 1 or 2
servers belonging to one's ISP). So how does the router know where to
go to?

That is what I meant when I said that there must be something implicit
in the PPPoE protocol.

Peter wrote:
>
> alexd<(E-Mail Removed)> wrote
>
>> No. The application, in this case ping, will resolve the IP address first,
>> and send the ICMP echo to that IP address. In other words, your PC will need
>> to have an idea of how to resolve IP addresses, usually by contacting a DNS
>> server.
>
> OK, but take a client PC whose TCP/IP DNS is e.g. 192.168.1.1 which is
> the router IP.
>
> Ignoring caching, in that case the *router* has to go and sort out the
> DNS.
>
> But, as in my config examples, a router which is connected via PPPoE
> has no config for a DNS server (e.g. 8.8.8.8 or more properly 1 or 2
> servers belonging to one's ISP). So how does the router know where to
> go to?
>
> That is what I meant when I said that there must be something implicit
> in the PPPoE protocol.

Conventionally, the router talks to the ISP to get both its own IP
address and the address of the ISP's DNS server(s), also a default
gateway at the ISP to which it sends all the outgoing traffic.

The key here is the PPP part of the protocol. The oA or oE means only
that the protocol is sent out of the border gateway device (generally a
router) over ATM (as in the case of the communication generated by an
ADSL router) or over Ethernet (in your case where the border gateway
device is the Sonicwall firewall) so the traffic is carried over
Ethernet to a modem.

The two are functionally equivalent. If a standard ADSL router can
connect to your ISP and can forward DNS requests to the ISP, then the
Sonicwall and modem combination should be able to do exactly the same.

It is likely that the Sonicwall can be configured to get its details
from the ISP's DHCP server. If the ISP issues you with a static IP
address then that is done at their end by them configuring their DHCP
server to give you the same address. You should not configure your end
with the static details - if you do, then you probably have to provide
th default gateway and DNS server details; which it is likely you don't
have or cannot change dynamically in response to changes made by the ISP.

Perhaps you should go back to the problem you're really trying to solve ....


--
Graham J

Graham J <graham@invalid> wrote

>The key here is the PPP part of the protocol. The oA or oE means only
>that the protocol is sent out of the border gateway device (generally a
>router) over ATM (as in the case of the communication generated by an
>ADSL router) or over Ethernet (in your case where the border gateway
>device is the Sonicwall firewall) so the traffic is carried over
>Ethernet to a modem.
>
>The two are functionally equivalent. If a standard ADSL router can
>connect to your ISP and can forward DNS requests to the ISP, then the
>Sonicwall and modem combination should be able to do exactly the same.

Nevertheless, in the Drayteks there is an option under PPPoE to
receive the IP and DNS data from the ISP, but there is no such option
under PPPoA. But it still works correctly, with NO nameserver IPs
configured anywhere (except on fixed-IP PCs on the LAN).

And there was no such option in the Sonicwall, when PPPoE was
configured. And it didn't work

>It is likely that the Sonicwall can be configured to get its details
>from the ISP's DHCP server.

I agree, but I could not see any config.

A friend of mine who knows far more about this than I do agrees that
the TZ100 should have just worked out of the box, in that basic mode.

>Perhaps you should go back to the problem you're really trying to solve ....

I will probably buy a Draytek 2920 and see how well it works. It looks
like a 2900, with a 3G fallback, and hopefully with some old bugs
fixed. The 2900 firmware was frozen in 2005.

I spoke to Draytek today (apparently in China) and they said the 2920
has "hardware VPN". However, an old review of the 2900 says that the
Samsung ARM processor has a DES/3DES co-processor, so probably little
had changed relative to real-world ADSL-VPN speeds of 448kbits/sec
max.

In article <(E-Mail Removed)>,
Peter <occassionally-(E-Mail Removed)> wrote:

>I spoke to Draytek today (apparently in China) and they said the 2920
>has "hardware VPN". However, an old review of the 2900 says that the
>Samsung ARM processor has a DES/3DES co-processor, so probably little
>had changed relative to real-world ADSL-VPN speeds of 448kbits/sec
>max.

I understood that the 2900s were basically the same internals as the
2600s but with an Ethernet port rather than ADSL, and when I tried them
with "modern" Internet speeds of some 8 years ago (ie. leased lines)
then they fell short in performance.

Actually, the case I had them in was a 10Mb line in Bristol and a bonded
T1 in the US (Ether presentation, so basically 3Mb) I found it could
keep up with the 3Mb line to the US but the jitter was very variable
- so much so that video over it (pair of polycom conferencing units)
wasn't very good. When I turned encryption off but otherwise left the
VPN going it was fine.

Gordon