PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001535PacketFenceupstreampublic2012-08-31 07:202012-09-13 10:57
Reporterfgaudreault 
Assigned Tofgaudreault 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version3.5.0 
Target VersionFixed in Version 
fixed in git revision986f432a2dc277819e76c8556b0e91d392e78169
fixed in mtn revision
Summary0001535: Inline mode and OSX DNS Caching issues for home page
DescriptionWhen visiting a mac based shop, we were having some issues using inline mode. Let me describe the problem that will impact most 10.6 users. 10.7 and 10.8 have the thin client browser that mitigate the issue, but the problem is still there is you use a real browser.

So what appears to happen is when you open a browser while unregistered, the browser will try to hit your home page. PacketFence will then resolve it to its inline ip address so that you can hit the portal. But, by doing so, the system caches the result, and when you are registered, the cache wins. When you try to go back to visit your home page, you won't be able to.

I was able to reproduce it all the time even with the ipset feature.

Now to fix this, why aren't we using DNAT for http/https traffic only if your mark is 0x2 or 0x3 (unreg/isol)? Let's resolve the real IP, but forward the packets to the inline interface for portal.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-08-31 07:20fgaudreaultNew Issue
2012-08-31 07:21fgaudreaultDescription Updated
2012-08-31 07:27obilodeauNote Added: 0002994
2012-08-31 07:28fgaudreaultNote Added: 0002995
2012-08-31 12:07fgaudreaultNote Added: 0003004
2012-09-10 14:42fgaudreaultNote Added: 0003037
2012-09-10 15:25obilodeauNote Added: 0003041
2012-09-11 09:29fgaudreaultNote Added: 0003045
2012-09-11 09:30fgaudreaultgit revision => b770fd2e04f63969b3a97d4a8534fe70960f5418
2012-09-11 09:36obilodeauNote Added: 0003046
2012-09-11 09:38fgaudreaultNote Added: 0003047
2012-09-13 10:57fgaudreaultgit revisionb770fd2e04f63969b3a97d4a8534fe70960f5418 => 986f432a2dc277819e76c8556b0e91d392e78169
2012-09-13 10:57fgaudreaultNote Added: 0003060
2012-09-13 10:57fgaudreaultStatusnew => resolved
2012-09-13 10:57fgaudreaultResolutionopen => fixed
2012-09-13 10:57fgaudreaultAssigned To => fgaudreault

Notes
(0002994)
obilodeau   
2012-08-31 07:27   
I think we would face the Apache vhost problem we had before doing DNS DNAT but I'm not sure.

Just an idea that I would like you to try: How about putting a TTL of 1 in named in inline? Could you try that?
(0002995)
fgaudreault   
2012-08-31 07:28   
Hmmm interesting. I can try to reduce the TTL of the zone yes. Ill let you know how it goes :)
(0003004)
fgaudreault   
2012-08-31 12:07   
TTL 1 fixed the problem.
(0003037)
fgaudreault   
2012-09-10 14:42   
Is the "TTL 1" a fair solution? I mean the only downside really is the number of DNS queries that the DNS server will have to handle. I am sure a decent server can handle it.
(0003041)
obilodeau   
2012-09-10 15:25   
Yes, I think we should go with the TTL of 1 approach.

I think we should do this change in a major release so we test thoroughly w/ several different devices before releasing.
(0003045)
fgaudreault   
2012-09-11 09:29   
Commited in devel with id b770fd2e04f63969b3a97d4a8534fe70960f5418

I don't think we need to test more, it has been live at a customer site since last week, and everything is A1.
(0003046)
obilodeau   
2012-09-11 09:36   
This could also help with javascript redirection in VLAN mode. Should we perform a similar change there?
(0003047)
fgaudreault   
2012-09-11 09:38   
Good idea. I think it will help too.
(0003060)
fgaudreault   
2012-09-13 10:57   
Fixed in devel.

Commit 986f432a2dc277819e76c8556b0e91d392e78169