This is a production issue that I have currently and would appreciate any ideas as to why and how this is happening . We have an SAP portal whose name has currently been changed . A lot of users still know the old name but there is a huge effort to direct users to the new name. The issue is that the developers have not customized the old site with the new name so they are using redirection from one site to another to acheieve their goal.
For eg : old site name : http://www.siteold.com and IP address 10.1.1.1 and new site name http://www.sitenew.com and IP 10.1.1.2 . So when a user makes a request to http://www.sitenew.com he/she is automatically redirected to http://www.siteold.com and the reply goes out from 10.1.1.1 . This is an issue because the original destination IP was 10.1.1.2 and now the reply is coming from 10.1.1.1 . While this is not an issue at most sites , we have users in military (DoD) sites where when they hit the new site they get a blank page.
My assumption is that because the return traffic is coming from an IP that was not the original destination IP , and that the DoD FW or IPS/IDS is expecting a reply from 10.1.1.2 , the return packet is dropped.
My question is what rules/signatures on the DoD firewall/IPS/IDS would drop this traffic .
I would really appreciate it if someone could help shed some light on this topic as it is a feature we would like to implement as well and because I do not know what rules would caue this drop ... I am unsure as to how to implement it.
I'm not sure if i understood ur problem right, but I really think that you will have to do something on a DNS level, to make this work ! I think URL forwarding is a little complicated..
My question is, the old site SAP server 10.1.1.1 , is it completely out of service ? no requests allowed onto that server ? If YES, then I would advice you to change the DNS registry for www.siteold.com to the new IP address 10.1.1.2, so that when the users login to http://www.siteold.com, they will hit the new server, and fetch data from that..
the new site name www.sitenew.com, can still ahve the same IP address, and point to 10.1.1.2.. By doing this, a DNS resolution happens, and the user is redirected on IP layer to 10.1.1.2... return path will also be from the same IP, and hence the firewalls/IDS should allow traffic back from 10.1.1.2 ..
Hope this helps.. all the best.. happy new year.. rate replies if found useful..
how is the redirection set up ?? I think normally application redirection happens through proxy mode.. redirection or forwarding, as per my knowledge, occurs in the following way :
1) there is a seperate TCP session between the newsite box and the oldsite server, on the destination IP address and port.. the user isnt aware of this redirection, as this happens at backend (say through some load balancers etc)
2) if it is a direct URL redirection, then the user should be directly put on to the oldsite hostname, and establishes a direct connectivity to it, throgh 10.1.1.1, and not 10.1.1.2 (since the new server has fully redirected traffic)..
There cant be a half-layer as u suggested, where the request goes to one server and the response comes back from another server ! You can probably run a sniffer and check this, as to where the response comes back from.. this seems some other issue..
I think the way it is redirected confuses me.. As far as the network goes, if you are able to open the application with the individual VIP's and URL's (www.oldsite.com, www.newsite.com), it should be good enough.. you should also be able to open the sites using the real IP's.. I'm really not sure how a apache server works.. probably you need to get more details on that, as to how the packets are forwarded, with the right source/destination ip addresses and ports.. then run a sniffer on the PC, to see what exactly is happening.. doing this will make you understand on a low-level as to what transactions are going on.. obviously, if the request goes to the newsite 10.1.1.2 and the response comes back from 10.1.1.1, the tcp session will not be established and will be dropped... it cant work this way.. do these:
1) talk to apache admin guys to understand the flow
2) do a telnet 10.1.1.1 80, 10.1.1.2 80 (if the application works on port 80), to confirm that there are no issues with DNS, and the network connectivity is fine..
3) If you already have a CSS, you can plan to have a single host entry , called www.newurl.com and map it to both the server groups (oldsite and newsite)... or you can keep the old URL's and change the VIP/RIP accordingly...
Thank you for taking the time to reply... but the problem is fixed .... The problem was actually not on the firewall side but as " A61971" suggested was with the IE browser security settings . Firefox worked ok . The problem was that a lot of users were using IE 6.0 with TLS 1.0 and Active Scripting disabled ( Military sites and some other sites ) . Enabling these settings made the redirect work.
Bascially the scenario that i had talked about earlier is not entirely correct . This is what was really happenning..
User -- Renamed URL @ 10.1.1.1 -- SYN
10.1.1.1 -- USER -- SYN ACK
User -- 10.1.1.1 -- ACK
User --- 10.1.1.1 -- SSL --CLIENT HELLO
10.1.1.1 -- User -- SSL -- SERVER HELLO
10.1.1.1 -- User -- Application Data ( The Apache server does a Hard redirect -- 304 )
10.1.1.1 -- User -- https > 1360 FIN ACK
User --10.1.1.1 --- 1360 > https FIN ACK
10.1.1.1 --- User -- https >1360 ACK
User --- 10.1.1.1 -- 1360 > Https ACK ... This is probably where the connection is closed and a new connection to the old URL is opened .
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :