The question , Setting up a fake AP - problem with iptables and DNS server , I posted before was answered and fixed, to not confuse people looking for the same problem in the future I wanted to post a new question that follows the problem I had but doesnt really have anything to do with it,since the former question was about my iptables and led to using a DNS server, this question is only about DNS and my hosts configuration or so I suspect, and the topic of this question is actually quite different.

I'm having some difficulty accessing websites using a bridged AP i made with aircrack-ng suite.

I cant access websites such as : yahoo, hotmail, google, CNN etc.. . But I can access several websites like facebook,youtube and addresss bar search with google engine works fine.
I have set my etc/dhcp/dhcpd.conf and my routing & IP tables entry as follows;
running iptables configuration and at0 routing rules(bash file):

ifconfig at0 up
ifconfig at0 netmask
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

running DHCP server : /etc/init.d/isc-dhcp-server start

/etc/dhcp/dhcpd.conf file:

default-lease-time 600;
max-lease-time 7200;
subnet netmask
    option subnet-mask;
    option domain-name "freewifi";
    option routers;
    option domain-name-servers;

The DNS server im using is the best offered DNS server using NameBench.py.

I'm getting this message on google for example, and its the same for many more websites: Unable to connect google

I can ping, but I cant apt-get or use wget, meaning I dont really have access to the internet(?) CacheFail

Using Kali Linux, MTU is 1500 , my speed is 5Mb/s using wireless connection. What is the problem here?

    I am able to connect directly to websites that I couldnt before if I type in the address bar: https://www.yahoo.com but if its without https it says unable to connect.

I read somewhere that mozila only allows HTTPS connections or it could be the Kali forcing HTTPS to make it secure. On WireShark I see many TCP DUP ACK'S and RST'S.

  • So to clarify, you can only access HTTPS and ICMP traffic ?
    – Purefan
    Jan 30, 2017 at 14:51
  • @Purefan exactly, I used wireshark and I get a lot of TCP Duplicate Acks and also many RST's, I can upload the wireshark file if necessary.
    – eyal360
    Jan 30, 2017 at 15:39
  • 1
    It is suppossed you have already running sslstrip python script, right? You didn't write it here but I know because I remember your other post... try without sslstrip. Comment out the line with iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000 and test normal surfing to locate exactly the problem. If it works, paste your sslstrip command. Ahh! and you have a typo... I hope that is not the problem right? when you say on sslstrip iptable rule --to- port you want to say --to-port without space after dash. Jan 30, 2017 at 15:50
  • @OscarAkaElvis Actually, I didnt use sslstrip in my code(thats why I didnt mention it), I want to see if I can surf the web normally before I do anything, I commented the line out and tried surfing again, still same problem. I tried to access to www.ebay.com >> Unable to connect , but I can ping www.ebay.com , so maybe something in the configurations?
    – eyal360
    Jan 30, 2017 at 16:12
  • 1
    Launching this without using the sslstrip command is normal to have problems with navigation.The iptables rule iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000 should be only if you have sslstrip launched.Otherwise, you are redirecting all traffic from tcp port 80 to port 10000 and there is nothing there to handle it. Anyway,without sslstriping and removing this line, you should navigate ok. Is understood that your wlan0 interface is which has internet access and is already connected to a network and you can navigate without problems from there. can you? Jan 30, 2017 at 17:04

1 Answer 1


After some comments, you are on the road... now you must locate exactly your problem. To launch sslstrip I can recommend you this nomenclature:

sslstrip -f -p -k -l 10000

-l to listen on port. so 10000 is default, you can avoid this or change port.
-k this kills possible previous sslstrip sessions in progress, recommended.
-f this change the favicon to a lock similar to used in https pages. It rocks if the victim uses old internet explorer versions, useless on chrome and firefox.
-p log only ssls POSTs

Of course if you launch this, you must activate the rule: iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000 as we said in previous comments.

I think you are doing good the commands... but sslstrip is a technique on which it depends not only on your side. If the "victim" use good built links like https://whatever.com you have nothing to do. He/she is going to ask directly always for an encrypted page.

So many people say "HSTS is the solution to sslstrip". And this is NOT TRUE. I did sslstrip a lot of times testing access to pages with HSTS and it works... they key as I said is the victim must do the http (without "s") initial request.

Another decisive factor is that not everypage can be sslstripped if you use common browsers on last versions since some years ago... I mean, if you use modern Chrome, Firefox or Internet Explorer for example... these browsers have an internal list of known ssl sites. That sites (like twitter or facebook for example) will never be sslstripped because the browser knows that ALWAYS must look for them using https even if the user did the "bad way request" putting facebook.com without specifying the https:// before. I guess these sites pay to the browser's companies to be in that list.

There are more advanced techniques to do sslstrip even to pages in that lists... like Delorean attack, or using sslstrip+ also called sslstrip2 which requires dns and proxy etc... but are more complicated.

I suggest to you try against not very known ssl pages because in that way there are less possibilities to crash in your tests against a site which is in that browser internal lists.

Good luck!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .